22.3.3 PDCP

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification

22.3.3.1 NB-IoT / Maintenance of PDCP sequence numbers / User plane / RLC AM

22.3.3.1.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE transmits a PDCP Data SDU on a DRB mapped on AM RLC }

then { UE increments SN with 1 for each transmitted PDU for SN=0 to Maximum_PDCP_SN }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE transmits a PDCP Data SDU on a DRB mapped on AM RLC and, after incrementation, Next_PDCP_TX_SN is larger than the Maximum_PDCP_SN }

then { UE sets SN to 0 in the next transmitted PDCP SDU}

}

22.3.3.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clause 5.1.1, 5.1.2.2 and 6.2.4.

[TS 36.323, clause 5.1.1]

At reception of a PDCP SDU from upper layers, the UE shall:

– start the discardTimer associated with this PDCP SDU (if configured);

For a PDCP SDU received from upper layers, the UE shall:

– associate the PDCP SN corresponding to Next_PDCP_TX_SN to this PDCP SDU;

NOTE: Associating more than half of the PDCP SN space of contiguous PDCP SDUs with PDCP SNs, when e.g., the PDCP SDUs are discarded or transmitted without acknowledgement, may cause HFN desynchronization problem. How to prevent HFN desynchronization problem is left up to UE implementation.

– perform header compression of the PDCP SDU (if configured) as specified in the subclause 5.5.4;

– perform integrity protection (if applicable), and ciphering (if applicable) using COUNT based on TX_HFN and the PDCP SN associated with this PDCP SDU as specified in the subclause 5.7 and 5.6, respectively;

– increment Next_PDCP_TX_SN by one;

– if Next_PDCP_TX_SN > Maximum_PDCP_SN:

– set Next_PDCP_TX_SN to 0;

– increment TX_HFN by one;

– submit the resulting PDCP Data PDU to lower layer.

[TS 36.323, clause 5.1.2.1.2]

For DRBs mapped on RLC AM, when the reordering function is not used, at reception of a PDCP Data PDU from lower layers, the UE shall:

– if received PDCP SN – Last_Submitted_PDCP_RX_SN > Reordering_Window or 0 <= Last_Submitted_PDCP_RX_SN – received PDCP SN < Reordering_Window:

– if received PDCP SN > Next_PDCP_RX_SN:

– decipher the PDCP PDU as specified in the subclause 5.6, using COUNT based on RX_HFN – 1 and the received PDCP SN;

– else:

– decipher the PDCP PDU as specified in the subclause 5.6, using COUNT based on RX_HFN and the received PDCP SN;

– perform header decompression (if configured) as specified in the subclause 5.5.5;

– discard this PDCP SDU;

– else if Next_PDCP_RX_SN – received PDCP SN > Reordering_Window:

– increment RX_HFN by one;

– use COUNT based on RX_HFN and the received PDCP SN for deciphering the PDCP PDU;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– else if received PDCP SN – Next_PDCP_RX_SN >= Reordering_Window:

– use COUNT based on RX_HFN – 1 and the received PDCP SN for deciphering the PDCP PDU;

– else if received PDCP SN >= Next_PDCP_RX_SN:

– use COUNT based on RX_HFN and the received PDCP SN for deciphering the PDCP PDU;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN is larger than Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– else if received PDCP SN < Next_PDCP_RX_SN:

– use COUNT based on RX_HFN and the received PDCP SN for deciphering the PDCP PDU;

– if the PDCP PDU has not been discarded in the above:

– perform deciphering and header decompression (if configured) for the PDCP PDU as specified in the subclauses 5.6 and 5.5.5, respectively;

– if a PDCP SDU with the same PDCP SN is stored:

– discard this PDCP SDU;

– else:

– store the PDCP SDU;

– if the PDCP PDU received by PDCP is not due to the re-establishment of lower layers:

– deliver to upper layers in ascending order of the associated COUNT value:

– all stored PDCP SDU(s) with an associated COUNT value less than the COUNT value associated with the received PDCP SDU;

– all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU;

– set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers;.

– else if received PDCP SN = Last_Submitted_PDCP_RX_SN + 1 or received PDCP SN = Last_Submitted_PDCP_RX_SN – Maximum_PDCP_SN:

– deliver to upper layers in ascending order of the associated COUNT value:

– all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU;

– set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers.

[TS 36.323, clause 6.2.4]

Figure 6.2.4.1 shows the format of the PDCP Data PDU when a 7 bit SN length is used. This format is applicable for PDCP Data PDUs carrying data from DRBs mapped on RLC UM or in NB-IoT DRBs mapped on RLC AM.

Figure 6.2.4.1: PDCP Data PDU format for DRBs using 7 bit SN

22.3.3.1.3 Test description

22.3.3.1.3.1 Pre-test conditions

System Simulator

– Ncell 1

– SS PDCP set to Transparent Mode

UE:

None.

Preamble

– The UE shall be in state 2B-NB with test loop mode A according to TS 36.508.

22.3.3.1.3.2 Test procedure sequence

Table 22.3.3.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Steps 1 and 2 shall be repeated for k=0 to Maximum_PDCP_SN (increment=1).

1

SS transmits a PDCP Data PDU on DRB1 containing one IP packet without header compression.

<–

PDCP Data PDU (SN = k)

2

CHECK: Does UE transmit a PDCP Data PDU with SN=0 for the first iteration and then incremented by 1 at each iteration?

–>

PDCP Data PDU (SN = k)

1

P

3

SS transmits a PDCP Data PDU on DRB1 containing one IP packet without header compression.

<–

PDCP Data PDU (SN = 0)

4

CHECK: Does UE transmit a PDCP Data PDU with SN=0?

–>

PDCP Data PDU (SN = 0)

2

P

5

SS sends a PDCP Data PDU on DRB1 containing one IP packet without header compression.

<–

PDCP Data PDU (SN = 1)

6

CHECK: Does UE transmit a PDCP Data PDU with SN=1?

–>

PDCP Data PDU (SN = 1)

1

P

22.3.3.1.3.3 Specific message contents

None

22.3.3.2 NB-IoT / Integrity protection / Ciphering and deciphering / Correct functionality of EPS AS and UP encryption algorithms / SNOW3G

22.3.3.2.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { Functionality of EPS AS encryption algorithms with SNOW 3G is taken into use }

then { UE performs correct AS ciphering function in PDCP entities associated with SRBs. }

}

(2)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {
when { Functionality of EPS AS integrity algorithms with SNOW3G is taken into use }

then { UE performs the integrity protection function in PDCP entities associated with SRBs. }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {
when { SecurityModeCommand fails the integrity protection check }

then { UE transmits SecurityModeFailure message and continues using the configuration used prior to the reception of the SecurityModeCommand message }

}

(4)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {
when { UE has AS security activated and integrity check fails }

then { UE initiates RRC connection re-establishment procedure }

}

(5)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE is requested to achieve functionality of EPS UP encryption algorithms with SNOW 3G }

then { UE performs correct UP ciphering function in PDCP entities associated with DRBs }

}

22.3.3.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.323, clause 5.6, clause 5.7, clause 5.1.2.2, TS 33.401, clause 5.1.3.2, clause 5.1.4.2 and TS 36.331, clause 6.3.3.

[TS 36.323, clause 5.6]

The ciphering function includes both ciphering and deciphering and is performed in PDCP. For the control plane, the data unit that is ciphered is the data part of the PDCP PDU (see subclause 6.3.3) and the MAC-I (see subclause 6.3.4). For the user plane, the data unit that is ciphered is the data part of the PDCP PDU (see subclause 6.3.3); ciphering is not applicable to PDCP Control PDUs.

For RNs, for the user plane, in addition to the data part of the PDCP PDU, the MAC-I (see 6.3.4) is also ciphered if integrity protection is configured.

The ciphering algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the ciphering method shall be applied as specified in [6].

The ciphering function is activated by upper layers [3]. After security activation, the ciphering function shall be applied to all PDCP PDUs indicated by upper layers [3] for the downlink and the uplink, respectively.

For downlink and uplink ciphering and deciphering, the parameters that are required by PDCP for ciphering are defined in [6] and are input to the ciphering algorithm. The required inputs to the ciphering function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]).The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (the ciphering keys for the control plane and for the user plane are KRRCenc and KUPenc, respectively).

[TS 36.323, clause 5.7]

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs and the SLRB that needs integrity protection. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

For RNs, the integrity protection function is performed also for PDCP entities associated with DRBs if integrity protection is configured.

The integrity protection algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the integrity protection method shall be applied as specified in [6].

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the downlink and the uplink, respectively.

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

For downlink and uplink integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3])

– KEY (KRRCint)

– for RNs, KEY (KUPint)

For the SLRB that needs integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value and DIRECTION (which value shall be set is specified in [13]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6])

– KEY (PIK)

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

[TS 36.323, clause 5.1.2.2]

– if integrity verification is not applicable:

– if received PDCP SN < Next_PDCP_RX_SN:

– increment RX_HFN by one;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN > Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– deliver the resulting PDCP SDU to upper layer;

– else, if integrity verification is applicable and the integrity verification fails:

– discard the received PDCP Data PDU;

– indicate the integrity verification failure to upper layer.

[TS 33.401, clause 5.1.3.2]

All algorithms specified in this subclause are algorithms with a 128-bit input key except Null ciphering algorithm.

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:

"00012" 128-EEA1 SNOW 3G based algorithm

"00102" 128-EEA2 AES based algorithm

"00112" 128-EEA3 ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2 for both RRC signalling ciphering and UP ciphering. UEs and eNBs may implement 128-EEA3 for both RRC signalling ciphering and UP ciphering.

UEs and MMEs shall implement EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering. UEs and MMEs may implement 128-EEA3 for NAS signalling ciphering.

[TS 33.401, clause 5.1.4.2]

All algorithms specified in this subclause are algorithms with a 128-bit input key.

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier. Currently, the following values have been defined:

"00002" EIA0 Null Integrity Protection algorithm

"00012" 128-EIA1 SNOW 3G based algorithm

"00102" 128-EIA2 AES based algorithm

"00112" 128-EIA3 ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling integrity protection. UEs and eNBs may implement 128-EIA3 for RRC signalling integrity protection.

UEs and MMEs shall implement 128-EIA1 and 128-EIA2 for NAS signalling integrity protection. UEs and MMEs may implement 128-EIA3 for NAS signalling integrity protection.

UEs shall implement EIA0 for integrity protection of NAS and RRC signalling. As specified in clause 5.1.4.1 of this specification, EIA0 is only allowed for unauthenticated emergency calls. EIA0 shall not be used for integrity protection between RN and DeNB.

Implementation of EIA0 in MMEs, RNs and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs, RNs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

[TS 36.331, clause 6.3.3]

The IE SecurityAlgorithmConfig is used to configure AS integrity protection algorithm (SRBs) and AS ciphering algorithm (SRBs and DRBs). For RNs, the IE SecurityAlgorithmConfig is also used to configure AS integrity protection algorithm for DRBs between the RN and the E-UTRAN.

Table 22.3.3.2.2-1: SecurityAlgorithmConfig field descriptions

cipheringAlgorithm

Indicates the ciphering algorithm to be used for SRBs and DRBs, as specified in TS 33.401 [32, 5.1.3.2].

integrityProtAlgorithm

Indicates the integrity protection algorithm to be used for SRBs, as specified in TS 33.401 [32, 5.1.4.2]. For RNs, also indicates the integrity protection algorithm to be used for integrity protection-enabled DRB(s).

22.3.3.2.3 Test description

22.3.3.2.3.1 Pre-test conditions

System Simulator:

– NCell 1.

UE:

– None.

Preamble:

– The UE shall be in State 3A-NB Registered, Idle Mode, UE Test Mode Activated for UE test loop mode A according to TS 36.508.

22.3.3.2.3.2 Test procedure sequence

Table 22.3.3.2.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS sends a Paging-NB message to the UE on the appropriate paging block, and including the UE identity in one entry of the IE pagingRecordList-NB.

<–

Paging-NB (PCCH)

2

Check: Does the UE transmit an RRCConnectionRequest-NB message on SRB0?

–>

RRCConnectionRequest-NB

3

Void

4

Void

5

The SS transmits an RRCConnectionSetup-NB message on SRB0.

<–

RRCConnectionSetup-NB

6

Check: Does the UE transmit an RRCConnectionSetupComplete-NB message on SRB1bis to confirm the successful completion of the connection establishment and to initiate the session management procedure by including the CONTROL PLANE SERVICE REQUEST message ?

–>

RRCConnectionSetupComplete-NB

1, 2

P

7

Void

8

Void

9

The SS transmits a SecurityModeCommand message on SRB1. MAC-I is calculated in such way, it will result in integrity check failure on UE side.

<–

SecurityModeCommand

10

Check: Does the UE transmit a SecurityModeFailure message on SRB1 without integrity protection nor ciphering?

–>

SecurityModeFailure

3

P

11

The SS transmits a SecurityModeCommand message on SRB1 to activate EPS AS encryption algorithm security. The message related PDCP Data PDU shall be integrity protected but not ciphered.

SecurityModeCommand

12

Check: Does the UE transmit a SecurityModeComplete message on SRB1 and establishes the initial security configuration without the message related PDCP Data PDU being ciphered (but integrity protected)?.

SecurityModeComplete

1, 2

P

13

Void

14

Void

15

The SS transmits a UECapabilityEnquiry-NB message on SRB1 to initiate the UE radio access capability transfer procedure. MAC-I is calculated in such way, it will result in integrity check failure on UE side.

<–

UECapabilityEnquiry-NB

16

Check: Does the UE transmit an RRCConnectionReestablishmentRequest-NB message on SRB0?

–>

RRCConnectionReestablishmentRequest-NB

4

P

17

The SS transmits a RRCConnectionReestablishment-NB message on SRB0

<–

RRCConnectionReestablishment-NB

18

The UE transmits RRCConnectionReestablishmentComplete-NB message on SRB1.

–>

RRCConnectionReestablishmentComplete-NB

19

Void

20

Void

21

The SS transmits an RRCConnectionReconfiguration-NB message on SRB1 to configure a new data radio bearer, associated with the default EPS bearer context. This message related PDCP Data PDU shall be integrity protected and ciphered. The COUNT of this message related PDCP Data PDU is used for deciphering.

<–

RRCConnectionReconfiguration-NB

22

Check: Does the UE transmit an RRCConnectionReconfigurationComplete-NB message being ciphered and integrity protected on SRB1 to confirm the establishment of the new data radio bearer, associated with the default EPS bearer context.

–>

RRCConnectionReconfigurationComplete-NB

1, 2

P

23

Void

24

Void

25-26

UE Test Loopback Activated procedure according to TS 36.508 clause 8.1.5.2B to activate loopback mode A for DRB1

27

SS transmits PDCP PDU on DRB1 ciphered.

<–

PDCP PDU

28

Check: Does the UE transmit looped back PDCP PDU ciphered.

–>

PDCP PDU

5

P

22.3.3.2.3.3 Specific message contents

Table 22.3.3.2.3.3-1 SecurityModeCommand (step 9 and 11, Table 22.3.3.2.3.2-1)

Derivation Path: TS36.508 clause 4.6.1 table 4.6.1-19

Information Element

Value/remark

Comment

Condition

SecurityModeCommand ::= SEQUENCE {

rrc-TransactionIdentifier

RRC-TransactionIdentifier-DL

criticalExtensions CHOICE {

c1 CHOICE{

securityModeCommand-r8 SEQUENCE {

securityConfigSMC SEQUENCE {

securityAlgorithmConfig SEQUENCE {

cipheringAlgorithm

eea1

integrityProtAlgorithm

eia1

}

}

nonCriticalExtension SEQUENCE {}

Not present

}

}

}

}

Table 22.3.3.2.3.3-2: RRCConnectionReestablishmentRequest-NB (step 16, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508, Table 8.1.6.1-7

Information Element

Value/remark

Comment

Condition

RRCConnectionReestablishmentRequest-RB ::= SEQUENCE {

criticalExtensions CHOICE {

rrcConnectionReestablishmentRequest-r13 SEQUENCE {

ue-Identity-r13 SEQUENCE {

c-RNTI

the value of the C-RNTI of the UE

physCellId

PhysicalCellIdentity of Cell 1

shortMAC-I

The same value as the 16 least significant bits of the XMAC-I value calculated by SS

}

reestablishmentCause-r13

otherFailure

}

}

}

Table 22.3.3.2.3.3-3: RRCConnectionReconfiguration-NB (step 21, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508 table 8.1.6.1-3

Information Element

Value/remark

Comment

Condition

RRCConnectionReconfiguration-NB ::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE{

rrcConnectionReconfiguration-r13 SEQUENCE {

dedicatedInfoNASList-r13

Not present

radioResourceConfigDedicated-r13

RadioResourceConfigDedicated-NB-DRB(1)

}

}

}

}

Table 22.3.3.2.3.3-4: Void

22.3.3.3 NB-IoT / Integrity protection / Ciphering and deciphering / Correct functionality of EPS AS and UP encryption algorithms / AES

22.3.3.3.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { Functionality of EPS AS encryption algorithms with AES is taken into use }

then { UE performs correct AS ciphering function in PDCP entities associated with SRBs. }

}

(2)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { Functionality of EPS AS integrity algorithms with AES is taken into use }

then { UE performs the integrity protection function in PDCP entities associated with SRBs. }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { SecurityModeCommand fails the integrity protection check }

then { UE transmits SecurityModeFailure message and continues using the configuration used prior to the reception of the SecurityModeCommand message }

}

(4)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE has AS security activated and integrity check fails }

then { UE initiates RRC connection re-establishment procedure }

}

(5)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE is requested to achieve functionality of EPS UP encryption algorithms with AES }

then { UE performs correct UP ciphering function in PDCP entities associated with DRBs. }

}

22.3.3.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.323, clause 5.6, clause 5.7, clause 5.1.2.2, TS 33.401, clause 5.1.3.2, clause 5.1.4.2 and TS 36.331, clause 6.3.3.

[TS 36.323, clause 5.6]

The ciphering function includes both ciphering and deciphering and is performed in PDCP. For the control plane, the data unit that is ciphered is the data part of the PDCP PDU (see subclause 6.3.3) and the MAC-I (see subclause 6.3.4). For the user plane, the data unit that is ciphered is the data part of the PDCP PDU (see subclause 6.3.3); ciphering is not applicable to PDCP Control PDUs.

For RNs, for the user plane, in addition to the data part of the PDCP PDU, the MAC-I (see 6.3.4) is also ciphered if integrity protection is configured.

The ciphering algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the ciphering method shall be applied as specified in [6].

The ciphering function is activated by upper layers [3]. After security activation, the ciphering function shall be applied to all PDCP PDUs indicated by upper layers [3] for the downlink and the uplink, respectively.

For downlink and uplink ciphering and deciphering, the parameters that are required by PDCP for ciphering are defined in [6] and are input to the ciphering algorithm. The required inputs to the ciphering function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]).The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (the ciphering keys for the control plane and for the user plane are KRRCenc and KUPenc, respectively).

[TS 36.323, clause 5.7]

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs and the SLRB that needs integrity protection. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

For RNs, the integrity protection function is performed also for PDCP entities associated with DRBs if integrity protection is configured.

The integrity protection algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the integrity protection method shall be applied as specified in [6].

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the downlink and the uplink, respectively.

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

For downlink and uplink integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (KRRCint).

– for RNs, KEY (KUPint)

For the SLRB that needs integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value and DIRECTION (which value shall be set is specified in [13]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]);

– KEY (PIK).

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

[TS 36.323, clause 5.1.2.2]

– if integrity verification is not applicable:

– if received PDCP SN < Next_PDCP_RX_SN:

– increment RX_HFN by one;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN > Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– deliver the resulting PDCP SDU to upper layer;

– else, if integrity verification is applicable and the integrity verification fails:

– discard the received PDCP Data PDU;

– indicate the integrity verification failure to upper layer.

[TS 33.401, clause 5.1.3.2]

All algorithms specified in this subclause are algorithms with a 128-bit input key except Null ciphering algorithm.

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:

"00012" 128-EEA1 SNOW 3G based algorithm

"00102" 128-EEA2 AES based algorithm

"00112" 128-EEA3 ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2 for both RRC signalling ciphering and UP ciphering. UEs and eNBs may implement 128-EEA3 for both RRC signalling ciphering and UP ciphering.

UEs and MMEs shall implement EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering. UEs and MMEs may implement 128-EEA3 for NAS signalling ciphering.

[TS 33.401, clause 5.1.4.2]

All algorithms specified in this subclause are algorithms with a 128-bit input key.

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier. Currently, the following values have been defined:

"00002" EIA0 Null Integrity Protection algorithm

"00012" 128-EIA1 SNOW 3G based algorithm

"00102" 128-EIA2 AES based algorithm

"00112" 128-EIA3 ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling integrity protection. UEs and eNBs may implement 128-EIA3 for RRC signalling integrity protection.

UEs and MMEs shall implement 128-EIA1 and 128-EIA2 for NAS signalling integrity protection. UEs and MMEs may implement 128-EIA3 for NAS signalling integrity protection.

UEs shall implement EIA0 for integrity protection of NAS and RRC signalling. As specified in clause 5.1.4.1 of this specification, EIA0 is only allowed for unauthenticated emergency calls. EIA0 shall not be used for integrity protection between RN and DeNB.

Implementation of EIA0 in MMEs, RNs and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs, RNs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

[TS 36.331, clause 6.3.3]

The IE SecurityAlgorithmConfig is used to configure AS integrity protection algorithm (SRBs) and AS ciphering algorithm (SRBs and DRBs). For RNs, the IE SecurityAlgorithmConfig is also used to configure AS integrity protection algorithm for DRBs between the RN and the E-UTRAN.

SecurityAlgorithmConfig field descriptions

cipheringAlgorithm

Indicates the ciphering algorithm to be used for SRBs and DRBs, as specified in TS 33.401 [32, 5.1.3.2].

integrityProtAlgorithm

Indicates the integrity protection algorithm to be used for SRBs, as specified in TS 33.401 [32, 5.1.4.2]. For RNs, also indicates the integrity protection algorithm to be used for integrity protection-enabled DRB(s).

22.3.3.3.3 Test description

22.3.3.3.3.1 Pre-test conditions

System Simulator:

– Ncell [1].

UE:

– None.

Preamble:

– The UE shall be in State 3-NB according to TS 36.508.

22.3.3.3.3.2 Test procedure sequence

Same Test procedure sequence as in table 22.3.3.2.3.2-1, except the ciphering and integrity protection algorithm is AES.

22.3.3.3.3.3 Specific message contents

Table 22.3.3.3.3.3-1 SecurityModeCommand-NB (step 9 and 11, Table 22.3.3.2.3.2-1)

Derivation Path: TS36.508 [clause 4.6.1 table 4.6.1-19]

Information Element

Value/remark

Comment

Condition

SecurityModeCommand ::= SEQUENCE {

rrc-TransactionIdentifier

RRC-TransactionIdentifier-DL

criticalExtensions CHOICE {

c1 CHOICE{

securityModeCommand-r8 SEQUENCE {

securityConfigSMC SEQUENCE {

securityAlgorithmConfig SEQUENCE {

cipheringAlgorithm

eea2

integrityProtAlgorithm

eia2

}

}

nonCriticalExtension SEQUENCE {}

Not present

}

}

}

}

Table 22.3.3.3.3.3-2: RRCConnectionReestablishmentRequest-NB (step 16, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508, Table 8.1.6.1-7

Information Element

Value/remark

Comment

Condition

RRCConnectionReestablishmentRequest-RB ::= SEQUENCE {

criticalExtensions CHOICE {

rrcConnectionReestablishmentRequest-r13 SEQUENCE {

ue-Identity-r13 SEQUENCE {

c-RNTI

the value of the C-RNTI of the UE

physCellId

PhysicalCellIdentity of Cell 1

shortMAC-I

The same value as the 16 least significant bits of the XMAC-I value calculated by SS

}

reestablishmentCause-r13

otherFailure

}

}

}

Table 22.3.3.3.3.3-3: RRCConnectionReconfiguration-NB (step 21, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508 table 8.1.6.1-3, condition [NB-DRB(1)]

Table 22.3.3.3.3.3-4: CLOSE UE TEST LOOP (step 25, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508 table 4.7A-3, condition [UE TEST LOOP MODE A]

22.3.3.4 NB-IoT / Integrity protection / Ciphering and deciphering / Correct functionality of EPS AS and UP encryption algorithms / ZUC

22.3.3.4.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { Functionality of EPS AS encryption algorithms with ZUC is taken into use }

then { UE performs correct AS ciphering function in PDCP entities associated with SRBs. }

}

(2)

with { UE in RRC_IDLE/E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { Functionality of EPS AS integrity algorithms with ZUC is taken into use }

then { UE performs the integrity protection function in PDCP entities associated with SRBs. }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { SecurityModeCommand fails the integrity protection check }

then { UE transmits SecurityModeFailure message and continues using the configuration used prior to the reception of the SecurityModeCommand message }

}

(4)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE has AS security activated and integrity check fails }

then { UE initiates RRC connection re-establishment procedure }

}

(5)

with { UE in E-UTRA RRC_CONNECTED state and network decides to use User plane CIoT EPS optimisation OR S1-U Data Transfer Only based on the UE capability }

ensure that {

when { UE is requested to achieve functionality of EPS UP encryption algorithms with ZUC }

then { UE performs correct UP ciphering function in PDCP entities associated with DRBs. }

}

22.3.3.4.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.323, clause 5.6, clause 5.7, clause 5.1.2.2, TS 33.401, clause 5.1.3.2, clause 5.1.4.2 and TS 36.331, clause 6.3.3.

[TS 36.323, clause 5.6]

The ciphering function includes both ciphering and deciphering and is performed in PDCP. For the control plane, the data unit that is ciphered is the data part of the PDCP PDU (see subclause 6.3.3) and the MAC-I (see subclause 6.3.4). For the user plane, the data unit that is ciphered is the data part of the PDCP PDU (see subclause 6.3.3); ciphering is not applicable to PDCP Control PDUs.

For RNs, for the user plane, in addition to the data part of the PDCP PDU, the MAC-I (see 6.3.4) is also ciphered if integrity protection is configured.

The ciphering algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the ciphering method shall be applied as specified in [6].

The ciphering function is activated by upper layers [3]. After security activation, the ciphering function shall be applied to all PDCP PDUs indicated by upper layers [3] for the downlink and the uplink, respectively.

For downlink and uplink ciphering and deciphering, the parameters that are required by PDCP for ciphering are defined in [6] and are input to the ciphering algorithm. The required inputs to the ciphering function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]).The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (the ciphering keys for the control plane and for the user plane are KRRCenc and KUPenc, respectively).

[TS 36.323, clause 5.7]

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs and the SLRB that needs integrity protection. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

For RNs, the integrity protection function is performed also for PDCP entities associated with DRBs if integrity protection is configured.

The integrity protection algorithm and key to be used by the PDCP entity are configured by upper layers [3] and the integrity protection method shall be applied as specified in [6].

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the downlink and the uplink, respectively.

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

For downlink and uplink integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (direction of the transmission: set as specified in [6]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity –1 as in [3]);

– KEY (KRRCint).

– for RNs, KEY (KUPint)

For the SLRB that needs integrity protection and verification, the parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value and DIRECTION (which value shall be set is specified in [13]). The parameters required by PDCP which are provided by upper layers [3] are listed below:

– BEARER (defined as the radio bearer identifier in [6]);

– KEY (PIK).

At transmission, the UE computes the value of the MAC-I field and at reception it verifies the integrity of the PDCP PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC corresponds to the received MAC-I, integrity protection is verified successfully.

[TS 36.323, clause 5.1.2.2]

– if integrity verification is not applicable:

– if received PDCP SN < Next_PDCP_RX_SN:

– increment RX_HFN by one;

– set Next_PDCP_RX_SN to the received PDCP SN + 1;

– if Next_PDCP_RX_SN > Maximum_PDCP_SN:

– set Next_PDCP_RX_SN to 0;

– increment RX_HFN by one;

– deliver the resulting PDCP SDU to upper layer;

– else, if integrity verification is applicable and the integrity verification fails:

– discard the received PDCP Data PDU;

– indicate the integrity verification failure to upper layer.

[TS 33.401, clause 5.1.3.2]

All algorithms specified in this subclause are algorithms with a 128-bit input key except Null ciphering algorithm.

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:

"00012" 128-EEA1 SNOW 3G based algorithm

"00102" 128-EEA2 AES based algorithm

"00112" 128-EEA3 ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2 for both RRC signalling ciphering and UP ciphering. UEs and eNBs may implement 128-EEA3 for both RRC signalling ciphering and UP ciphering.

UEs and MMEs shall implement EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering. UEs and MMEs may implement 128-EEA3 for NAS signalling ciphering.

[TS 33.401, clause 5.1.4.2]

All algorithms specified in this subclause are algorithms with a 128-bit input key.

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list below.

Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier. Currently, the following values have been defined:

"00002" EIA0 Null Integrity Protection algorithm

"00012" 128-EIA1 SNOW 3G based algorithm

"00102" 128-EIA2 AES based algorithm

"00112" 128-EIA3 ZUC based algorithm

The remaining values have been reserved for future use.

UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling integrity protection. UEs and eNBs may implement 128-EIA3 for RRC signalling integrity protection.

UEs and MMEs shall implement 128-EIA1 and 128-EIA2 for NAS signalling integrity protection. UEs and MMEs may implement 128-EIA3 for NAS signalling integrity protection.

UEs shall implement EIA0 for integrity protection of NAS and RRC signalling. As specified in clause 5.1.4.1 of this specification, EIA0 is only allowed for unauthenticated emergency calls. EIA0 shall not be used for integrity protection between RN and DeNB.

Implementation of EIA0 in MMEs, RNs and eNBs is optional, EIA0, if implemented, shall be disabled in MMEs, RNs and eNBs in the deployments where support of unauthenticated emergency calling is not a regulatory requirement.

[TS 36.331, clause 6.3.3]

The IE SecurityAlgorithmConfig is used to configure AS integrity protection algorithm (SRBs) and AS ciphering algorithm (SRBs and DRBs). For RNs, the IE SecurityAlgorithmConfig is also used to configure AS integrity protection algorithm for DRBs between the RN and the E-UTRAN.

Table 22.3.3.4.2-1: SecurityAlgorithmConfig field descriptions

cipheringAlgorithm

Indicates the ciphering algorithm to be used for SRBs and DRBs, as specified in TS 33.401 [32, 5.1.3.2].

integrityProtAlgorithm

Indicates the integrity protection algorithm to be used for SRBs, as specified in TS 33.401 [32, 5.1.4.2]. For RNs, also indicates the integrity protection algorithm to be used for integrity protection-enabled DRB(s).

22.3.3.4.3 Test description

22.3.3.4.3.1 Pre-test conditions

System Simulator:

– Ncell [1].

UE:

– None.

Preamble:

– The UE shall be in State 3-NB according to TS 36.508.

22.3.3.4.3.2 Test procedure sequence

Same Test procedure sequence as in table 22.3.3.2.3.2-1, except the ciphering and integrity protection algorithm is ZUC.

22.3.3.4.3.3 Specific message contents

Table 22.3.3.4.3.3-1 SecurityModeCommand-NB (step 9 and 11, Table 22.3.3.2.3.2-1)

Derivation Path: TS36.508 [clause 4.6.1 table 4.6.1-19]

Information Element

Value/remark

Comment

Condition

SecurityModeCommand ::= SEQUENCE {

rrc-TransactionIdentifier

RRC-TransactionIdentifier-DL

criticalExtensions CHOICE {

c1 CHOICE{

securityModeCommand-r8 SEQUENCE {

securityConfigSMC SEQUENCE {

securityAlgorithmConfig SEQUENCE {

cipheringAlgorithm

eea3-v1130

integrityProtAlgorithm

eia3-v1130

}

}

nonCriticalExtension SEQUENCE {}

Not present

}

}

}

}

Table 22.3.3.4.3.3-2: RRCConnectionReestablishmentRequest-NB (step 16, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508, Table 8.1.6.1-7

Information Element

Value/remark

Comment

Condition

RRCConnectionReestablishmentRequest-RB ::= SEQUENCE {

criticalExtensions CHOICE {

rrcConnectionReestablishmentRequest-r13 SEQUENCE {

ue-Identity-r13 SEQUENCE {

c-RNTI

the value of the C-RNTI of the UE

physCellId

PhysicalCellIdentity of Cell 1

shortMAC-I

The same value as the 16 least significant bits of the XMAC-I value calculated by SS

}

reestablishmentCause-r13

otherFailure

}

}

}

Table 22.3.3.4.3.3-3: RRCConnectionReconfiguration-NB (step 21, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508 table 8.1.6.1-3, condition [NB-DRB(1)]

Table 22.3.3.4.3.3-4: CLOSE UE TEST LOOP (step 25, Table 22.3.3.2.3.2-1)

Derivation Path: 36.508 table 4.7A-3, condition [UE TEST LOOP MODE A]

22.3.3.5 NB-IoT / PDCP re-establishment / stored UE AS context is used and drb-ContinueROHC is configured

22.3.3.5.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_IDLE state and upper layers indicate stored UE AS context }

ensure that {

when { UE is requested to resume a suspended RRC connection }

then { UE transmits next PDCP Data PDU with SN value 0 }

}

22.3.3.5.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.3.4a and 3GPP TS 36.523 clause 5.2.1.2

[TS 36.331, clause 5.3.3.4a]

Reception of the RRCConnectionResume by the UE

1> stop timer T300;

1> restore the PDCP state and re-establish PDCP entities for SRB2 and all DRBs;

1> if drb-ContinueROHC is included:

2> indicate to lower layers that stored UE AS context is used and that drb-ContinueROHC is configured;

2> continue the header compression protocol context for the DRBs configured with the header compression protocol;

1> else:

2> indicate to lower layers that stored UE AS context is used;

2> reset the header compression protocol context for the DRBs configured with the header compression protocol;

1> discard the stored UE AS context and resumeIdentity;

1> perform the radio resource configuration procedure in accordance with the received radioResourceConfigDedicated and as specified in 5.3.10;

1> resume SRB2 and all DRBs;

[TS 36.323, clause 5.2.1.2]

When upper layers request a PDCP re-establishment, the UE shall:

– reset the header compression protocol for uplink and start with an IR state in U-mode [9] [11] if the DRB is configured with the header compression protocol and drb-ContinueROHC is not configured [3];

– set Next_PDCP_TX_SN, and TX_HFN to 0;

– apply the ciphering algorithm and key provided by upper layers during the re-establishment procedure;

– if connected as an RN, apply the integrity protection algorithm and key provided by upper layers (if configured) during the re-establishment procedure;

– for each PDCP SDU already associated with a PDCP SN but for which a corresponding PDU has not previously been submitted to lower layers:

– consider the PDCP SDUs as received from upper layer;

– perform transmission of the PDCP SDUs in ascending order of the COUNT value associated to the PDCP SDU prior to the PDCP re-establishment, as specified in the subclause 5.1.1 without restarting the discardTimer.

22.3.3.5.3 Test description

22.3.3.5.3.1 Pre-test conditions

System Simulator:

– Ncell 1 according to TS 36.508 [18] Table 8.1.4.2-1A.

UE:

None.

Preamble:

– The UE is in State 2B-NB, Attach Connected Mode, UE Test Loopback Activated for UE test loop mode B on Ncell 1 (serving cell) according to TS 36.508 [18] clause 8.1.5.2A.

22.3.3.5.3.2 Test procedure sequence

Table 22.3.3.5.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS creates 3 IP Packets.

EXCEPTION: Step 2 and 3 shall be repeated

for k=0 to 1 (increment=1).

2

The SS transmits one IP packet to the UE on the DRB associated with the default EPS bearer context.

<-

IP Packet #k

3

The UE loops back the IP packet received in Step 2 on the DRB associated with the default EPS bearer context.

->

IP Packet #k

4

SS transmits an RRCConnectionRelease-NB

Message. (IE ReleaseCause-r13 with Value rrc-Suspend).

<-

RRCConnectionRelease-NB

5

Wait for 10 s for the UE to enter E-UTRA

RRC_IDLE state on Ncell 1.

6

The SS transmits a Paging-NB message with a matching UE identity.

<-

Paging-NB

7

The UE transmits RRCConnectionResumeRequest-NB message.

->

RRCConnectionResumeRequest-NB

8

The SS transmits RRCConnectionResume-NB message with drb-ContinueROHC-r13 present.

<-

RRCConnectionResume-NB

9

The UE transmits RRCConnectionResumeComplete-NB message to confirm the successful completion of an RRC connection resumption.

->

RRCConnectionResumeComplete-NB

10-11

Void

12

The SS transmits one IP packet to the UE on the DRB associated with the default EPS bearer context.

<-

IP Packet

13

Check: Does the UE loop back the IP packet on the DRB associated with the default EPS bearer context with PDCP SN=0?

->

IP Packet

1

P

22.3.3.5.3.3 Specific message contents

Table 22.3.3.5.3.3-1: PDCP-Config-NB (RRCConnectionReconfiguration-NB message in Preamble)

Derivation Path: 36.331 clause 6.7.3.2

Information Element

Value/remark

Comment

Condition

PDCP-Config-NB-r13 ::= SEQUENCE {

headerCompression-r13 CHOICE {

rohc SEQUENCE {

maxCID-r13

The IE shall be set to the value of maxNumberROHC-ContextSessions parameter as indicated by the UE in UECapabilityInformation

profiles-r13 SEQUENCE {

profile0x0002

One of the profile shall be set to TRUE based on the parameter supportedROHC-Profiles as indicated by the UE in UECapabilityInformation. If support of more than one ROHC profile are indicated, then the profile corresponding to the highest value shall be set to TRUE

profile0x0003

profile0x0004

profile0x0006

profile0x0102

profile0x0103

profile0x0104

}

}

}

}

Table 22.3.3.5.3.3-2: RRCConnectionRelease-NB message (step 4, Table 22.3.3.5.2-1)

Derivation Path: 36.508 clause 8.1.6.1-9

Information Element

Value/remark

Comment

Condition

RRCConnectionRelease-NB ::= SEQUENCE {

rrc-TransactionIdentifier

criticalExtensions CHOICE {

c1 CHOICE {

rrcConnectionRelease-r13 SEQUENCE {

releaseCause-r13

rrc-suspend

resumeIdentity-r13

BIT STRING (SIZE(40))

Any value

extendedWaitTime-r13

Not present

redirectedCarrierInfo

Not present

lateNonCriticalExtension

Not present

nonCriticalExtension SEQUENCE {}

Not present

}

}

}

}

Table 22.3.3.5.3.3-3: RRCConnectionResume-NB message (step 8, Table 22.3.3.5.2-1)

Derivation Path: 36.508 table 8.1.6.1-11

Information Element

Value/remark

Comment

Condition

RRCConnectionRelease-NB ::= SEQUENCE {

rrc-TransactionIdentifier

criticalExtensions CHOICE {

c1 CHOICE {

rrcConnectionResume-r13 SEQUENCE {

radioResourceConfigDedicated-r13

RadioResourceConfigDedicated-NB-exPDCP

nextHopChainingCount-r13

0

drb-ContinueROHC-r13

true

lateNonCriticalExtension

Not present

nonCriticalExtension SEQUENCE {}

Not present

}

}

}

}

Table 22.3.3.5.3.3-4: RadioResourceConfigDedicated-NB-DRB-exPDCP

Derivation Path: 36.508 Table 8.1.6.3-11

Information Element

Value/remark

Comment

Condition

RadioResourceConfigDedicated-NB-DRB-exPDCP ::= SEQUENCE {

drb-ToAddModList-r13 SEQUENCE (SIZE (1.. maxDRB-NB-r13)) OF SEQUENCE {

one entry

drb-ToAddMod-r13[1]

DRB-ToAddMod-NB-exPDCP (1)

}

}

Table 22.3.3.5.3.3-5: DRB-ToAddMod-NB-exPDCP(bid)

Derivation Path: 36.508 Table 8.1.8.2.1.7-1

Information Element

Value/remark

Comment

Condition

DRB-ToAddMod-NB- exPDCP (bid) ::= SEQUENCE {

pdcp-Config-r13

Not present

}

22.3.3.6 NB-IoT / PDCP Discard

22.3.3.6.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { the Discard Timer for a PDCP SDU expires }

then { UE discards the corresponding PDCP SDU }

}

22.3.3.6.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clause 5.9

[TS 36.323, clause 5.4]

When the Discard_Timer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by PDCP status report, the UE shall discard the PDCP SDU along with the corresponding PDCP PDU. If the corresponding PDCP PDU has already been submitted to lower layers the discard is indicated to lower layers.

22.3.3.6.3 Test description

22.3.3.6.3.1 Pre-test conditions

System Simulator:

– Ncell 1 according to TS 36.508 [18] Table 8.1.4.2-1A.

UE:

None.

Preamble:

– The UE is in state Loopback Activated for UE test loop mode A (State 2B-NB) on Ncell 1 (serving cell) according to TS 36.508 [18] clause 8.1.5.2A with the exceptions listed in table 22.3.3.6.3.1-1 applicable for the configured AM DRB.

Table 22.3.3.6.3.1-1: PDCP Settings

Parameter

Value

discardTimer-r13

5120 ms

22.3.3.6.3.2 Test procedure sequence

Table 22.3.3.6.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS creates 5 PDCP Data PDUs with 32 bytes of different SDU data each and the Next_PDCP_TX_SN is set to "0".

EXCEPTION: Step 2 shall be repeated for k=0 to 2

(increment=1) with the below specified PDU sent to the UE:

Data PDU#1 for k=0

Data PDU#2 for k=1

Data PDU#3 for k=2

2

The SS sends a PDCP Data PDU via RLC-AM RB

with the following content to the UE:

D/C field = 1 (PDCP Data PDU) and PDCP SN = k

After having sent a PDU, the SS sets Next_PDCP_TX_SN = k+1.

<-

PDCP DATA PDU (SN=k)

3

Wait for Discard_Timer to expire.

Note: Timer tolerances according to TS 36.508 [18] clause 8.3.7 are applied.

EXCEPTION: Step 4 shall be repeated for k=3 to 4

(increment=1) with the below specified PDU sent to the UE:

Data PDU#4 for k=3

Data PDU#5 for k=4

4

The SS sends a PDCP Data PDU via RLC-AM RB

with the following content to the UE:

D/C field = 1 (PDCP Data PDU) and PDCP SN = k

After having sent a PDU, the SS set

Next_PDCP_TX_SN = k+1.

<-

PDCP DATA PDU (SN=k)

5

The SS allocates UL grant of size 296 bits for the next NPDCCH period (Note 3).

6

Check: Does UE transmit a PDCP Data PDU # 4? (Note 2)

->

PDCP Data PDU # 4

1

P

7

Check: Does UE transmit a PDCP Data PDU # 5? (Note 2)

->

PDCP Data PDU # 5

1

P

NOTE 1: Void.

NOTE 2: PDCP Data PDU contents are checked to verify that the UL PDU is same as the DL P DU. According to the note in TS 36.323 [38] clause 5.1.1 in case of PDCP SDUs being dicarded it is up to UE implementation which SN to be used and therefore the SN cannot be checked.

NOTE 3: UL grant of 296 bits (ITBS=9, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Padding subheader + 1 byte MAC SDU subheader, 35 bytes MAC SDU(2 bytes RLC AMD PDU header + 1 byte PDCP PDU header + 32 bytes UL RLC SDU))DU.

22.3.3.6.3.3 Specific message contents

None.