GSM Association Non-confidential

Official Document TS.40 - MIoT Field and Lab Test Cases

MIoT Field and Lab Test Cases

Version 2.0
22 December 2017

This is a Non-binding Permanent Reference Document of the GSMA

Security Classification: Non-confidential

Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the
Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and
information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted
under the security classification without the prior written approval of the Association.

Copyright Notice
Copyright © 2018 GSM Association

Disclaimer
The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept
any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.
The information contained in this document may be subject to change without prior notice.

Antitrust Notice
The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy.

V2.0 Page 1 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Table of Contents
1 Introduction 4
1.1 Overview 4
1.2 Scope 4
1.1 Classification of Individual Test Scenarios 5
1.2 Definitions 5
1.3 Abbreviations 8
1.4 References 10
2 Basic Operation 11
2.1 Registration (Attach/Detach) 11
2.1.1 CAT-M1 Device Attach Procedure with Control Plane CIoT EPS
Optimization 11
2.1.2 CAT-M1 Device Attach Procedure with User Plane CIoT EPS
Optimization 13
2.1.3 CAT-M1 Device Attach Procedure with CIoT EPS Optimization (EMM
Registered without PDN Connection) 15
2.1.4 CAT-NB1 Device Attach Procedure with Control Plane CIoT EPS
Optimization – without PDN 17
2.1.5 CAT-NB1 Device Attach Procedure with Control Plane CIoT EPS
Optimization – with PDN 19
2.1.6 CAT-NB1 Device Attach Procedure with User Plane CIoT EPS
Optimization – without PDN 21
2.1.7 CAT-NB1 Device Attach Procedure with User Plane CIoT EPS
Optimization – with PDN 22
2.1.8 CAT-NB1 Device Attach Procedure with CIoT EPS Optimizations (SMS
transfer without Combined Attach) 24
2.1.9 Attach Procedure / Reject / No suitable cell in TA (EMM cause #15) 26
2.1.10 Device Detach Procedure Description 27
2.2 Paging 27
2.2.1 Paging Procedure 27
2.3 Data Transfer 28
2.3.1 Data Transfer use IP/non-IP/SMS with CP/UP 28
2.3.2 Suspend Resume 31
2.3.3 Serving PLMN Rate Control / APN Rate Control 34
2.4 Mobility Performance 36
2.4.1 IDLE-Mode Mobility 36
2.4.2 Connected Mode Mobility 39
2.5 Device Capabilities 41
2.5.1 CAT-NB1 Uplink Transmission Capability – 3.7kHz (Single-tone) 41
2.5.2 CAT-NB1 Uplink Transmission Capability - 15kHz (Single-tone) 42
2.5.3 CAT-NB1 Uplink Transmission Capability - 15kHz (Multi-tone) 42
3 Device Performance in Enhanced Coverage 43
3.1 Registration 43
3.1.1 Attach Performance with Control Plane CIoT EPS Optimizations 43

V2.0 Page 2 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

3.1.2 Attach Performance with User Plane CIoT EPS Optimizations 44

3.2 Paging 45
3.2.1 Paging performance under different coverage level 45
3.2.2 Paging with eDRX cycle under different coverage level 45
3.3 Data Transfer and Throughput 46
3.3.1 Data Transfer and Throughput with Control Plane CIoT EPS
Optimizations - IP PDN Type 46
3.3.2 Data Transfer and Throughput with Control Plane CIoT EPS
Optimizations - Non IP PDN Type 47
3.3.3 Data Transfer and Throughput with User Plane CIoT EPS Optimizations
- IP PDN Type 48
3.3.4 Data Transfer and Throughput with User Plane CIoT EPS Optimizations
- Non IP PDN Type 49
3.4 Mobility Performance 49
3.4.1 Idle Mode Mobility Performance – Cell Reselection 49
3.4.2 Connected Mode Mobility Performance 50
4 Power Optimized Operation 51
4.1 PSM Operation 51
4.1.1 PSM Request, Activation and Modification 51
4.1.2 MT Data in PSM State 52
4.1.3 MO Data in PSM State 52
4.1.4 Periodic Tracking Area Update 53
4.1.5 Periodic Tracking Area Update, T3412 54
4.1.6 Reduced Current Drain in PSM 55
4.1.7 Periodic Tracking Area Update Power Consumption Performance 56
4.2 I-eDRX Operation 57
4.2.1 eDRX Request, Activation and Modification 57
4.2.2 Power Consumption in Idle State with eDRX 58
4.3 Data transmission power consumption 59
4.3.1 CAT-M1 Device Uplink Transmission Power Consumption 59
4.3.2 CAT-NB1 Device Uplink Transmission Power Consumption 60
4.3.3 Downlink Transmission Power Consumption 61
5 Service Layer 62
5.1 oneM2M 62
5.2 LwM2M 62
6 USIM/eUICC OTA 63
7 USIM Toolkit 63
8 Antenna Performance 63
9 Device Management (LwM2M) 63
10 Mapping of Test Cases to Requirements 64
Annex A Individual Test Scenario Classification and Proforma 71
Annex B Document Management 72
B.1 Document History 72
B.2 Other Information 72

V2.0 Page 3 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

1 Introduction

1.1 Overview
This document contains a set of guidelines for the tests that should be performed in the
course of Field Test and Lab Test carried out on LPWA (Low Power Wide Area) Mobile IoT
modules and devices.

Field Tests are tests undertaken during later phases of the terminal development against a
real live deployed network (i.e. in the field) to prove of a feature or technology.

Lab Tests are tests undertaken during later phases of the terminal development against
laboratory based network components, representative of a real deployed network, to prove a
feature or technology.

Field Tests are required to ensure confidence in the performance of Mobile IoT modules and
devices in the operational network environment. Lab Tests usually complement Field Tests
for scenarios which cannot be easily executed in a live network.

It is assumed that Field Tests shall be performed without direct support from the network
operator. However TSG and its operator delegates do offer their assistance, if required by
any Manufacturer in terms of drafting Field and/or Lab Tests, providing network specific
information, etc.

The Field and/or Lab Tests in this document may be performed in any order that is
convenient. Only the features supported by the DUT shall be tested.

It is recommended to use a logging tool, if available, to take log files when running the tests.
The log files and their indication of network conditions/behaviour during the tests will help to
remove any ambiguity that may come out of the test results.

Also more specifically about the performances tests, it is recommended to run the tests with
the terminal to be certified and with a reference terminal such as, a competitive terminal
available on the market. The behaviour of the reference platform will help to remove any
ambiguity about the test results.

In order to provide visibility on the applicability, extent and the result of Field and/or Lab
Tests conducted on Mobile IoT modules and devices, Annex A has been included in this
document.

1.2 Scope
This document defines all test cases for PTCRB and GCF Certification of LPWA MIoT
modules and devices that are to be deployed in mobile networks that support LPWA
modules and devices.

These test cases shall be executed against the requirements document as identified within
the MIoT Requirements document TS.39 V2.0 which reflects the specifications as identified
in the 3GPP Rel 13 Specifications published in June 2016.

V2.0 Page 4 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

This document does not replicate any test cases that are currently defined within the GSMA
Device Connection Efficiency Test Book TS.35 [9]. Any test cases in this respect will be
agreed between the respective MNO’s and their Vendors and is outside the scope of this
document.

It should be noted that the test cases listed within this document are those that are deemed
as a priority by the MNOs for accreditation of MIoT devices onto their networks.

1.1 Classification of Individual Test Scenarios

Every individual test scenario is classified in Field Test, Lab Test or both. This classification
should adhere to the following criteria:

Field Test only:

 Confidence is only given that this feature works correctly when it has been tested in
the field on real live commercial networks.
 It is possible to execute this test in the field (assuming there are live commercial
network deployments).
 The only exception to this rule is when a vendor wishes to test a feature for which
there are no commercial network deployments. In this case the feature MAY be lab
tested for the purpose of gaining some basic confidence in the feature. If this option is
used by the vendor then only a ‘provisional pass’ of the test can be achieved and this
must clearly be marked in the vendors test report.

Lab Test only:

 Technically, it is only practical for this test to be executed in a lab.

 Executing this test in the lab MAY not give the same level of confidence that the
feature will work correctly on real live networks, however it may provide some basic
confidence in the feature.
 For the identification of absolute performance of the handset, it is better to perform
this test in a controlled (Lab-) environment, where resources are allocated only for the
handset.

Both, Field Test and Lab Test:

 If there are severe practical difficulties in executing this test in the field then this test
MAY be executed in a lab.
 There is equal confidence in the proper function of this feature regardless of whether
it is tested in the Field or Lab environment. Passing the test in the lab is therefore
equally valid as passing the test in the field.

The individual classification of a test scenario is listed in Annex A.

1.2 Definitions
The key words "SHALL", "SHOULD" and "MAY", within this document are to be interpreted
as described in RFC 2119 [19], an abstract of which is included within the table below.

V2.0 Page 5 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Term Description

MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is
an absolute requirement of the specification.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional.
One vendor may choose to include the item because a particular marketplace
requires it or because the vendor feels that it enhances the product while
another vendor may omit the same item. An implementation which does not
include a particular option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with reduced
functionality. In the same vein an implementation which does include a
particular option MUST be prepared to be interoperate with another
implementation which does not include the option (except, of course, for the
feature the option provides.)
Physical entity (person, company or organisation) that can assume a Role in
Actor the functional architecture. It is possible for an Actor to assume multiple Roles
in the same functional architecture.

Any device that is used to help fulfil the field trial requirement.
A Client may be a cellular device, software client, a server, a system simulator
Client or other device used to complete a test, if not defined otherwise in Initial
Configuration
These additional devices are by default identified as Client-1, Client-2, Client-
3, … etc.
Connectivity A set of data (for example SMSC address) required by the eUICC to open a
Parameters communication channel (for example SMS, HTTPS) on a dedicated network.

Customer A paying party, in particular a legally responsible juridical person or entity.

Equipment into which an Embedded UICC and a communication module are

Device
inserted during assembly. Examples include Utility meter, car and camera.

The state of a Profile where all files and applications (for example NAA)
Disabled (Profile)
present in the Profile are not selectable over the eUICC-Terminal interface.

A UICC which is not easily accessible or replaceable, is not intended to be

Embedded UICC
removed or replaced in the Device, and enables the secure changing of
(eUICC)
Profiles.

The state of a Profile when its files and/or applications (for example, NAA) are
Enabled (Profile)
selectable over the UICC-Terminal interface.

eUICC Supplier of the eUICCs and resident software (for example firmware and
Manufacturer operating system).

International
Unique identifier owned and issued by Mobile operators to (U) SIM
Mobile Subscriber
applications to enable Devices to attach to a network and use services.
Identity

V2.0 Page 6 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Term Description

A Mobile IoT (MIoT) Device is a generic term to indicate one of the following
MIoT Device 3GPP standard technologies for LPWA: CAT-M1, CAT-NB1 and EC-GSM-
IoT.

Mobile Network An entity providing access capability and communication services to its
Operator Customers through a mobile network infrastructure.

A communications module complying with one or more of the 3GPP

communication technologies such as 2G, 3G, EC-GSM-IoT, CAT-NB1 or
3GPP module
CAT-M1, this includes all necessary eUICC or UICC components. Can also
be called User Equipment or UE.

Network Access An application residing on a UICC which provides authorisation to access a

Application network for example a USIM application.

Combination of a file structure, data and applications to be provisioned onto,

Profile or present on, an eUICC and which allows, when enabled, the access to a
specific mobile network infrastructure.

A Profile Component is an element of the Profile and may be one of the

following:

An element of the file system like an MF, EF or DF

Profile Component
An Application, including NAA and Security Domain

POL1

MNO-SD.

A specific device with similar capabilities as the DUT that has already been
successfully field trialed for the test being performed, if not defined otherwise
in Initial Configuration.

This is used when a performance or behavior comparison is required to

Reference Device confirm the pass criteria of the DUT.

These additional devices are by default identified as Reference-1, Reference-

2, Reference-3, etc.

See also Client.

Roles Roles are representing a logical grouping of functions.

Subscriber Identity Module; a physical entity that contains keys and ID

required to authenticate a user on a mobile network. “SIM” is commonly used
SIM to refer to the physical entity that is technically called the UICC (see UICC
definition below).This document generally uses “SIM” to refer to the physical
entity

V2.0 Page 7 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Term Description

An entity (associated with one or more users) that is engaged in a

Subscription with a Telecommunication Service Provider. The Subscriber is
Subscriber allowed to subscribe and unsubscribe to services, to register a user or a list of
users authorised to use those services, and also to set the limits relative to
the use that associated users make of those services.

Describes the commercial relationship between the Subscriber and the

Subscription
Telecommunication Service Provider.

Subscription
Role that prepares the Profiles and manages the secure download and
Manager Data
installation of these Profiles onto the eUICC.
Preparation

Subscription
Role that securely performs functions of Platform Management commands
Manager Secure
and the transport of Profile Management commands.
Routing

The organization through which the Subscriber obtains PLMN

Telecommunication
telecommunication services. This is usually the network operator or possibly a
Service Provider
separate body.

A route preferably provided by the operator and contains ideally all mobility
scenarios supported by the operator’s network.
In case no Test Route is or can be provided by the operator a test route will
Test Route
follow the limited set below.
In both cases the test route should not exceed 50 km in length or can be
completed in approximately 30 min. during off-peak hours and normal road
traffic conditions.
Universal Integrated Circuit Card; the physical entity that contains as a
UICC
minimum the SIM/USIM application

An application that runs on the UICC and provides authentication functions

USIM
similar to those provided by the SIM in pre-3G systems

1.3 Abbreviations
Term Description

3GPP 3rd Generation Partnership Project

BGA Ball Grid Array
CAT-NB1 Category Narrow Band 1
CAT-M1 Category M1
C-DRX Connected mode DRX
CIoT Cellular Internet of Things
dB Decibel
dBm Decibel-referenced to 1 milliwatt
DFN Dual Flat No lead package
DRX Discontinuous Reception
DL Downlink

V2.0 Page 8 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Term Description

DUT Device Under Test

E-DRX Extended DRX
ETSI European Telecommunications Standards Institute
EC-GSM-IoT Extended Coverage GSM Internet of Things
EDGE Enhanced Data Rates for GSM Evolution
eDRX Extended Discontinuous Receive
EGPRS Enhanced General packet radio service
eUICC Embedded Universal Integrated Circuit Card
FDD Frequency Division Duplexing
GERAN GSM EDGE Radio Access Network
GPRS General Packet Radio Service
GMSK Gaussian minimum shift keying
GSM Global System for Mobile Communications
GSMA GSM Association
I-DRX Idle mode DRX
IoT Internet of Things
IMEI International Mobile Station Equipment Identity
IP Internet Protocol
IPSec Internet Protocol Security
LoRa Long Range
LPUC Low Power Use Case
LPWA Low Power Wide Area
LTE Long-Term Evolution
LTE eMTC Long-Term Evolution Enhanced Machine Type Communications
LTE MTC Long-Term Evolution Machine Type Communications
M2M Machine-to-machine
MCL Maximum Coupling Loss
MFF2 M2M Form Factor 2
MHz Mega Hertz
MNO Mobile Network Operator
MS Mobile Station
MTC Machine Type Communications
NB-IoT Narrow Band Internet of Things
OFDMA Orthogonal Frequency-Division Multiple Access
OTA Over The Air
PLMN Public Land Mobile Network
PSM Power Save Mode

V2.0 Page 9 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Term Description

QoS Quality of Service

RAN Radio Access Network
RF Radio Frequency
SC-FDMA Single-carrier frequency-division multiple access
SIM Subscriber Identity Module (an application running on a UICC)
SMS Short Message Service
TA Tracking Area
TAU Tracking Area Update
TCO Total Cost of Ownership
TDMA Time division multiple access
TR Technical Report
UE User Equipment
UICC Universal Integrated Circuit Card (sometimes known as the SIM card)
UL Uplink
USIM Universal Subscriber Identity Module
UTDOA Uplink-Time Difference of Arrival
WAN Wide Area Network
Wi-Fi Wireless Fidelity
WLCSP Wafer-level redistribution Chip Scale Package

1.4 References
Ref Doc Number Title
UICC-Terminal Interface; Physical, electrical and logical
[1] 3GPP TS 31.120
test specification, Release 13 or higher.
“UICC-Terminal interface; Universal Subscriber Identity
[2] 3GPP TS 31.121 Module (USIM) application test specification, Release 13
or higher.
Mobile Equipment (ME) conformance test specification;
Universal Subscriber Identity Module Application Toolkit
[3] 3GPP TS 31.124
(USAT) conformance test specification, Release 13 or
higher.
OMA-ETS-
Enabler Test Specification for Lightweight M2M v1.0,
[4] LightweightM2M-
publication date 20170830 or later.
V1_0_1
oneM2M TS
[5] oneM2M Interoperability Testing
0013
oneM2M TS
[6] oneM2M Implementation Conformance Statements
0017
oneM2M TS
[7] oneM2M Test Suite Structure and Test Purposes
0018

V2.0 Page 10 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Ref Doc Number Title

oneM2M TS oneM2M Abstract Test Suite & Implementation eXtra
[8]
0019 Information for Test
IoT Device Connection Efficiency Test Book, Version 3.0,
[9] GSMA TS.35
30 March 2016
User Equipment (UE) / Mobile Station (MS) Over The Air (OTA)
[10] 3GPP TS.34.114
antenna performance; Conformance testing
Universal Terrestrial Radio Access (UTRA) and Evolved
[11] 3GPP TS.37.544 UTRA (E-UTRA); User Equipment (UE) Over The Air
(OTA) performance; Conformance testing
CTIA OTA Test
[12] Test Plan for Wireless Device Over-the-Air Performance
Plan v3.6
[13] RFC2119 Key words for use in RFCs to Indicate Requirement Levels
Evolved Universal Terrestrial Radio Access (E-UTRA);
[14] 3GPP TS.36.304
User Equipment (UE) procedures in idle mode
Evolved Universal Terrestrial Radio Access (E-UTRA);
[15] 3GPP TS36.321
Medium Access Control (MAC) protocol specification
Evolved Universal Terrestrial Radio Access (E-UTRA);
[16] 3GPP TS.36.331
Radio Resource Control (RRC); Protocol specification

2 Basic Operation

2.1 Registration (Attach/Detach)

2.1.1 CAT-M1 Device Attach Procedure with Control Plane CIoT EPS
Optimization
Description
CAT-M1 device could successfully perform LTE Attach Procedure with Control Plane CIoT
EPS Optimizations.
Related core specifications
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-M1 device could successfully perform LTE Attach Procedure with Control
Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-M1 and “Control Plane CIoT EPS Optimizations”
Test procedure

V2.0 Page 11 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Switch on DUT DUT is in EMM-IDLE mode reads SIB2; set
up RRC connection and sends Attach
Request message indicating support of
“Control Plane CIoT EPS Optimization”
together with PDN CONNECTIVITY
REQUEST Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete after reception of Attach from NW DUT successfully completes
2
Accept message from NW attach procedure by sending Attach
Complete Message

Example message flow:

Direction
Step Message Comments
UE - NW
After DUT has read SIB-2 to
verify that “Control Plane
CIoT EPS Optimizations” is
1a --> RRC: RRCConnection Request
broadcast in EUTRAN Cell
it sends RRC Connection
Request
1b <-- RRC: RRCConnectionSetup
RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST indicates support of “Control
1c -->
NAS: PDN CONNECTIVITY REQUEST Plane CIoT EPS
Optimization”
RRC: DLInformationTransfer
1d <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer
1e -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer
1f <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer
1g -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer
1h <--
NAS: ESM INFORMATION REQUEST
RRC: ULInformationTransfer
1i -->
NAS: ESM INFORMATION RESPONSE
1j <-- RRC: SecurityModeCommand
1k --> RRC: SecurityModeComplete
1l <-- RRC: UECapabilityEnquiry

V2.0 Page 12 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
RRC: UECapabilityInformation RRC UE Capability
Information Message will
include E-UTRAN
1m -->
parameter, Inter-RAT
parameter and Radio
Paging Information
RRC: RRCConnectionReconfiguration
NAS: ATTACH ACCEPT
2a <--
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST
2b --> RRC: RRCConnectionReconfigurationComplete
RRC: ULInformationTransfer
NAS: ATTACH COMPLETE
2c -->
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPT

2.1.2 CAT-M1 Device Attach Procedure with User Plane CIoT EPS
Optimization
Description
CAT-M1 device could successfully perform LTE Attach Procedure with User Plane CIoT
EPS Optimizations.
Related core specifications
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-M1 device could successfully perform LTE Attach Procedure with User
Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-M1 and “User Plane CIoT EPS Optimizations” and
“S1-U Data transfer”.
Test procedure

V2.0 Page 13 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Switch on DUT DUT is in EMM-IDLE mode reads SIB2-BR;
set up RRC connection and sends Attach
Request message indicating support of
“User Plane CIoT EPS Optimization” and
“S1-U Data transfer” together with PDN
CONNECTIVITY REQUEST Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete after reception of Attach from NW DUT successfully completes
Accept message from NW attach procedure by sending Attach
2
Complete Message together with Activate
Default EPS Bearer Context Accept
Message

Example message flow (optional):

Direction
Step Message Comments
UE - NW
RRC: RRCConnection Request
After DUT has read SIB2 to
verify that “User Plane CIoT
EPS Optimizations” is
1a -->
broadcast in EUTRAN Cell
it sends RRC Connection
Request

1b <-- RRC: RRCConnectionSetup

RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST indicates support of “User
1c --> NAS: PDN CONNECTIVITY REQUEST Plane CIoT EPS
Optimization” and “S1-U
Data Transfer”
RRC: DLInformationTransfer
1d <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer
1e -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer
1f <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer
1g -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer
1h <--
NAS: ESM INFORMATION REQUEST
RRC: ULInformationTransfer
1i -->
NAS: ESM INFORMATION RESPONSE
1j <-- RRC: SecurityModeCommand
1k --> RRC: SecurityModeComplete

V2.0 Page 14 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
1l <-- RRC: UECapabilityEnquiry
RRC: UECapabilityInformation RRC UE Capability
Information Message will
include E-UTRAN
1m -->
parameter, Inter-RAT
parameter and Radio
Paging Information
RRC: RRCConnectionReconfiguration
NAS: ATTACH ACCEPT
2a <--
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST
2b --> RRC: RRCConnectionReconfigurationComplete
RRC: ULInformationTransfer
NAS: ATTACH COMPLETE
2c -->
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPT

2.1.3 CAT-M1 Device Attach Procedure with CIoT EPS Optimization (EMM
Registered without PDN Connection)
Description
CAT-M1 device could successfully perform LTE Attach Procedure with CIoT EPS
Optimizations without PDN connection.
Related core specifications
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-M1 device could successfully perform LTE Attach Procedure with CIoT
EPS Optimizations without PDN connection.
Initial configuration
DUT is configured with “attachwithoutPDN Connectivity” in “Preferred and Supported
Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-M1 and “attachwithoutPDN Connectivity”
Test procedure

V2.0 Page 15 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Switch on DUT DUT is in EMM-IDLE mode reads SIB2; set
up RRC connection and sends Attach
Request message indicating support of
“attachwithoutPDN Connectivity” in UE
Network Capability IE together with ESM
DUMMY Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete with ESM DUMMY from NW DUT successfully completes
2
MESSAGE after reception of Attach Accept attach procedure by sending Attach
message from NW Complete Message

Example message flow (optional):

Direction
Step Message Comments
UE - NW
After DUT has read SIB2 to
verify that
“attachwithoutPDN” is
1a --> RRC: RRCConnectionRequest
broadcast in EUTRAN Cell
it sends RRC Connection
Request
1b <-- RRC: RRCConnectionSetup
RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST specifies support of
1c --> NAS: ESM DUMMY MESSAGE “attachwithoutPDN
Connectivity in UE Network
Capability IE
RRC: DLInformationTransfer
1d <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer
1e -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer
1f <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer
1g -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer
1h <--
NAS: ESM INFORMATION REQUEST
RRC: ULInformationTransfer
1i -->
NAS: ESM INFORMATION RESPONSE
1j <-- RRC: SecurityModeCommand
1k --> RRC: SecurityModeComplete
1l <-- RRC: UECapabilityEnquiry

V2.0 Page 16 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
RRC: UECapabilityInformation RRC UE Capability
Information Message will
include E-UTRAN
1m -->
parameter, Inter-RAT
parameter and Radio
Paging Information
RRC: RRCConnectionReconfiguration NW sends Attach Accept
NAS: ATTACH ACCEPT Message that supports
2a <-- NAS: ESM DUMMY MESSAGE “attachwithoutPDN
Connectivity” in “EPS
Network Feature Support”
2b --> RRC: RRCConnectionReconfigurationComplete
RRC: ULInformationTransfer
2c --> NAS: ATTACH COMPLETE
NAS: ESM DUMMY MESSAGE

2.1.4 CAT-NB1 Device Attach Procedure with Control Plane CIoT EPS
Optimization – without PDN
Description
CAT-NB1 device could successfully perform LTE Attach Procedure with Control Plane CIoT
EPS Optimizations.
Related core specifications
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-NB device could successfully perform LTE Attach Procedure with Control
Plane CIoT EPS Optimizations with PDN.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations with PDN” in “Preferred and
Supported Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-NB1 and “Control Plane CIoT EPS Optimizations”
Test procedure

V2.0 Page 17 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Switch on DUT DUT in EMM_IDLE mode reads SIB2-NB;
set up RRC connection and sends Attach
Request message indicating support of
“Control Plane CIoT EPS Optimization”
together with PDN CONNECTIVITY
REQUEST Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete after reception of Attach from NW DUT successfully completes
2
Accept message from NW attach procedure by sending Attach
Complete Message

Example message flow:

Direction
Step Message Comments
UE - NW
After DUT has read SIB2-
NB to verify that “Control
Plane CIoT EPS
1a --> RRC: RRCConnection Request-NB
Optimizations” is broadcast
in EUTRAN Cell it sends
RRC Connection Request
1b <-- RRC: RRCConnectionSetup-NB
RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST indicates support of “Control
1c -->
NAS: ESM DUMMY MESSAGE Plane CIoT EPS
Optimization”
RRC: DLInformationTransfer-NB
1d <--
NAS: IDENTITY REQUEST
RRC: ULInformationTransfer-NB
1e -->
NAS: IDENTITY RESPONSE
RRC: DLInformationTransfer-NB
1f <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer-NB
1g -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer-NB
1h <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer-NB
1i -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer-NB
2a <-- NAS: ATTACH ACCEPT
NAS: ESM DUMMY MESSAGE
RRC: ULInformationTransfer-NB
2b --> NAS: ATTACH COMPLETE
NAS: ESM DUMMY MESSAGE
2c <-- RRC: RRCConnectionRelease-NB

V2.0 Page 18 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.1.5 CAT-NB1 Device Attach Procedure with Control Plane CIoT EPS
Optimization – with PDN
Description
CAT-NB1 device could successfully perform LTE Attach Procedure with Control Plane CIoT
EPS Optimizations.
Related core specifications
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-NB1 device could successfully perform LTE Attach Procedure with
Control Plane CIoT EPS Optimizations with PDN.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations with PDN” in “Preferred and
Supported Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-NB1 and “Control Plane CIoT EPS Optimizations”
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT in EMM_IDLE mode reads SIB2-NB;
set up RRC connection and sends Attach
Request message indicating support of
“Control Plane CIoT EPS Optimization”
together with PDN CONNECTIVITY
REQUEST Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete after reception of Attach from NW DUT successfully completes
2
Accept message from NW attach procedure by sending Attach
Complete Message

V2.0 Page 19 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Example message flow:

Direction
Step Message Comments
UE - NW
After DUT has read SIB-2 to
verify that “Control Plane
CIoT EPS Optimizations” is
1a --> RRC: RRCConnection Request-NB
broadcast in EUTRAN Cell
it sends RRC Connection
Request
1b <-- RRC: RRCConnectionSetup-NB
RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST indicates support of “Control
1c -->
NAS: PDN CONNECTIVITY REQUEST Plane CIoT EPS
Optimization”
RRC: DLInformationTransfer-NB
1d <--
NAS: IDENTITY REQUEST
RRC: ULInformationTransfer-NB
1e -->
NAS: IDENTITY RESPONSE
RRC: DLInformationTransfer-NB
1f <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer-NB
1g -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer-NB
1h <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer-NB
1i -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer-NB
1j <--
NAS: ESM INFORMATION REQUEST
RRC: ULInformationTransfer-NB
1k -->
NAS: ESM INFORMATION RESPONSE
RRC: DLInformationTransfer-NB
NAS: ATTACH ACCEPT
2a <--
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST
RRC: ULInformationTransfer-NB
NAS: ATTACH COMPLETE
2b -->
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPT
2c <-- RRC: RRCConnectionRelease-NB

V2.0 Page 20 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.1.6 CAT-NB1 Device Attach Procedure with User Plane CIoT EPS
Optimization – without PDN
Description
CAT-NB1 device could successfully perform LTE Attach Procedure with User Plane CIoT
EPS Optimizations without PDN connection.
Related core specifications
GSMA TS.39_2.1.2_REQ_001 (Cell Selection Procedure)
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-NB1 device could successfully perform LTE Attach Procedure with User
Plane CIoT EPS Optimizations without PDN.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations without PDN” in “Preferred and
Supported Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-NB1 and “User Plane CIoT EPS Optimizations without
PDN-Connectivity”
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT in EMM_IDLE mode reads SIB2-NB;
set up RRC connection and sends Attach
Request message indicating support of
“User Plane CIoT EPS Optimization”
together with ESM DUMMY Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete after reception of Attach from NW DUT successfully completes
2
Accept message from NW attach procedure by sending Attach
Complete Message

Example message flow:

Direction
Step Message Comments
UE - NW
After DUT has read SIB2-
NB to verify that “User
Plane CIoT EPS
Optimizations” and “EPS
1a --> RRC: RRCConnection Request-NB
Attach without PDN
Connectivity” is
broadcasted in EUTRAN
Cell

V2.0 Page 21 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
1b <-- RRC: RRCConnectionSetup-NB
RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST indicates support of “User
NAS: ESM DUMMY MESSAGE Plane CIoT EPS
1c -->
Optimization” and “EPS
Attach without PDN
connectivity”
RRC: DLInformationTransfer-NB
1d <--
NAS: IDENTITY REQUEST
RRC: ULInformationTransfer-NB
1e -->
NAS: IDENTITY RESPONSE
RRC: DLInformationTransfer-NB
1f <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer-NB
1g -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer-NB
1h <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer-NB
1i -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer-NB
2a <-- NAS: ATTACH ACCEPT
NAS: ESM DUMMY MESSAGE
RRC: ULInformationTransfer-NB
2b --> NAS: ATTACH COMPLETE
NAS: ESM DUMMY MESSAGE
2c <-- RRC: RRCConnectionRelease-NB

2.1.7 CAT-NB1 Device Attach Procedure with User Plane CIoT EPS
Optimization – with PDN
Description
CAT-NB1 device could successfully perform LTE Attach Procedure with User Plane CIoT
EPS Optimizations with PDN connection.
Related core specifications
GSMA TS.39_2.1.2_REQ_001 (Cell Selection Procedure)
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-NB1 device could successfully perform LTE Attach Procedure with User
Plane CIoT EPS Optimizations with PDN.

V2.0 Page 22 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations with PDN” in “Preferred and
Supported Network Behaviour”
DUT is Switched OFF
The NW is configured to support CAT-NB1 and “User Plane CIoT EPS Optimizations”
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT in EMM_IDLE mode reads SIB2-NB;
set up RRC connection and sends Attach
Request message indicating support of
“User Plane CIoT EPS Optimization”
together with PDN CONNECTIVITY
REQUEST Message.
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete after reception of Attach from NW DUT successfully completes
2
Accept message from NW attach procedure by sending Attach
Complete Message

Example message flow:

Direction
Step Message Comments
UE - NW
After DUT has read SIB2-
NB to verify that “User
Plane CIoT EPS
1a --> RRC: RRCConnection Request-NB
Optimizations” is broadcast
in EUTRAN Cell it sends
RRC Connection Request
1b <-- RRC: RRCConnectionSetup-NB
RRC: RRCConnectionSetupComplete Attach Request message
NAS: ATTACH REQUEST indicates support of “User
1c -->
NAS: PDN CONNECTIVITY REQUEST Plane CIoT EPS
Optimization”
RRC: DLInformationTransfer-NB
1d <--
NAS: IDENTITY REQUEST
RRC: ULInformationTransfer-NB
1e -->
NAS: IDENTITY RESPONSE
RRC: DLInformationTransfer-NB
1f <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer-NB
1g -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer-NB
1h <--
NAS: SECURITY MODE COMMAND

V2.0 Page 23 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
RRC: ULInformationTransfer-NB
1i -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer-NB
1j <--
NAS: ESM INFORMATION REQUEST
RRC: ULInformationTransfer-NB
1k -->
NAS: ESM INFORMATION RESPONSE
RRC: DLInformationTransfer-NB
NAS: ATTACH ACCEPT
2a <--
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST
RRC: ULInformationTransfer-NB
NAS: ATTACH COMPLETE
2b -->
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT ACCEPT
2c <-- RRC: RRCConnectionRelease-NB

2.1.8 CAT-NB1 Device Attach Procedure with CIoT EPS Optimizations (SMS
transfer without Combined Attach)
Description
Check that CAT-NB1 device could successfully perform LTE Attach Procedure for “SMS
transfer without Combined Attach”.
Related core specifications
GSMA TS.39_2.1.2_REQ_001 (Cell Selection Procedure)
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-NB1 device could successfully perform LTE Attach Procedure for “SMS
transfer without Combined Attach”
Initial configuration
DUT configured with “SMS transfer without Combined Attach” and “Control Plane CIoT EPS
Optimizations” in “Preferred and Supported Network Behaviour”.
The NW is configured to support “SMS transfer without Combined Attach” and “Control
Plane CIoT EPS Optimizations”.
DUT is Switched OFF
Test procedure

V2.0 Page 24 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Switch on DUT DUT set up RRC connection and sends
Attach Request message indicating support
of "SMS only"
Verify the DUT sends Attach Upon reception of Attach Accept message
AcceptComplete together with Activate from NW DUT successfully completes
Default EPS Bearer Context Accept Message attach procedure by sending Attach
2
in the ESM Message Container Information Complete Message
Element after reception of Attach Accept
message from NW

Direction
Step Message Comments
UE - NW
After DUT has read SIB2 to
verify that “Control Plane
CIoT EPS Optimizations” is
1a --> RRC: RRCConnectionRequest-NB
broadcast in EUTRAN Cell
it sends RRC Connection
Request
1b <-- RRC: RRCConnectionSetup-NB
RRC: RRCConnectionSetupComplete-NB Attach Request message
NAS: ATTACH REQUEST indicates support of "SMS
NAS: PDN CONNECTIVITY REQUEST only" in the additional
(optional) update type IE and shall set
the EPS attach type IE to
"EPS attach"
1c -->
optional:
PDN CONNECTIVITY
REQUEST Message in
ESM Message Container
Information Element to
request PDN Connectivity
RRC: DLInformationTransfer-NB
1d <--
NAS: AUTHENTICATION REQUEST
RRC: ULInformationTransfer-NB
1e -->
NAS: AUTHENTICATION RESPONSE
RRC: DLInformationTransfer-NB
1f <--
NAS: SECURITY MODE COMMAND
RRC: ULInformationTransfer-NB
1g -->
NAS: SECURITY MODE COMPLETE
RRC: DLInformationTransfer-NB
1h <--
NAS: ESM INFORMATION REQUEST
RRC: ULInformationTransfer-NB
1i -->
NAS: ESM INFORMATION RESPONSE
1j <-- RRC: SecurityModeCommand

V2.0 Page 25 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
1k --> RRC: SecurityModeComplete
1l <-- RRC: UECapabilityEnquiry
RRC: UECapabilityInformation RRC UE Capability
Information Message will
include E-UTRAN
1m -->
parameter, Inter-RAT
parameter and Radio
Paging Information
RRC: RRCConnectionReconfiguration-NB
NAS: ATTACH ACCEPT
2a <--
NAS: ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST (optional)
RRC:
2b -->
RRCConnectionReconfigurationComplete-NB
RRC: ULInformationTransfer Optional:
NAS: ATTACH COMPLETE Activate Default EPS
NAS: ACTIVATE DEFAULT EPS BEARER Bearer Context Accept
2c -->
CONTEXT ACCEPT (optional) Message in the ESM
Message Container
Information Element

2.1.9 Attach Procedure / Reject / No suitable cell in TA (EMM cause #15)

Description
Check an CAT-M1 or CAT-NB1 device behaviour on the reject message with cause 15 ‘No
suitable cells in TA’ in an MIoT environment that is incompatible with DUTs’ CIoT EPS
optimisation.
Related core specifications
GSMA TS.39_2.1.2_REQ_001 (Cell Selection Procedure)
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
GSMA TS.39_2.2.2_REQ_005 (Reject Cause)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-M1 or CAT-NB1 DUT behaves correctly on a reject message ‘‘No suitable
cell in TA” from the E-UTRA cell. The DUT shall indicate the loss of service with an
appropriate error message (e.g. limited service).
Initial configuration
DUT and NW configured “CIoT EPS Optimizations” are not compatible.
DUT is Switched OFF
Test procedure

V2.0 Page 26 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Switch on DUT DUT in EMM_IDLE mode reads SIB2-NB;
set up RRC connection and sends Attach
Request message indicating support of
“CIoT EPS Optimization”.
Verify the DUT enters EMM Upon reception of Attach Reject with EMM
DEREGISTERED.LIMITED-SERVICE and cause value #15 (no suitable cell in TA)
2
indicates appropriate error message upon from NW the DUT enters
EMM reject cause #15. EMM.DEREGISTERED.LIMITED-SERVICE

2.1.10 Device Detach Procedure Description

CAT-M1 or CAT-NB1 device could successfully perform Detach Procedure.
Related core specifications
GSMA TS.39_2.2.2_REQ_002 (Detach)
3GPP TS 23.401, 24.301 and 36.331
Reason for test
To verify that CAT-M1 or CAT-NB1 device could successfully perform Detach Procedure.
Initial configuration
DUT is configured with “CIoT EPS Optimizations” in “Preferred and Supported Network
Behaviour”
DUT is Switched ON (EMM-REGISTERED)
The NW is configured to support “CIoT EPS Optimizations”
Test procedure

Step Test procedure Expected behaviour

1 Switch off DUT DUT in EMM-REGISTERED sends
DETACH REQUEST message for a period
of 5 s. The DUT switches off as soon as the
detach message has been sent.

2.2 Paging

2.2.1 Paging Procedure

Description
The CAT-NB1 and CAT-M1 device should initiate RRC connection establishment, when
receiving the Paging message, e.g. to receive an incoming call.
Related core specifications
3GPP TS 36.331.
Reason for test
To verify that CAT-NB1 and CAT-M1 device could successfully initiate RRC connection
establishment, when receiving the Paging message.

V2.0 Page 27 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Initial configuration
DUT is in RRC_IDLE.
The NW supports the paging procedure when downlink data request is generated.
Test procedure

Step Test procedure Expected behaviour

DUT set up the RRC connection
Downlink data request is sent to DUT in
1 establishment upon receiving the paging
RRC_IDLE
message.
Verify the DUT successfully establish RRC DUT successfully establish RRC
2
Connection and act as requested. Connection and act as requested.

2.3 Data Transfer

2.3.1 Data Transfer use IP/non-IP/SMS with CP/UP

2.3.1.1 Data Transfer with Control Plane CIoT EPS Optimizations - IP PDN Type
Description
Data transfer via IP
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.211, TS 36.213
TS.39_2.4.2_REQ_001
Reason for test
Verify CAT-M1 and CAT-NB1 device can transport data use IP PDN Type with Control Plane
CIoT EPS Optimizations.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support IP PDN Type
DUT is in RRC_CONNECTED State.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT DUT sends ESM DATA TRANSPORT
message which contains IP data
2 Perform downlink data transfer on DUT DUT receives ESM DATA TRANSPORT
message which contains IP data

2.3.1.2 Data Transfer with Control Plane CIoT EPS Optimizations - Non IP PDN
Type
Description

V2.0 Page 28 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Data transfer via non-IP

Related core specifications
3GPP TS 23.401,3GPP TS 24.301, TS 36.211, TS 36.213
TS.39_2.4.2_REQ_001
Reason for test
Verify CAT-M1 and CAT-NB1 device can transport data use Non IP PDN Type with Control
Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support Non IP PDN Type
DUT is in RRC_CONNECTED State.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT DUT sends ESM DATA TRANSPORT
message which contains Non IP data
2 Perform downlink data transfer on DUT DUT receives ESM DATA TRANSPORT
message which contains Non IP data

2.3.1.3 Data Transfer with User Plane CIoT EPS Optimizations - IP PDN Type
Description
Data transfer via IP
Related core specifications
3GPP TS 23.401,3GPP TS 24.301, TS 36.211, TS 36.213
TS.39_2.4.2_REQ_001
Reason for test
Verify CAT-M1 and CAT-NB1 device can transport data use IP PDN Type with User Plane
CIoT EPS Optimizations.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support IP PDN Type
DUT is in RRC_CONNECTED State.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT DUT sends ESM DATA TRANSPORT
message which contains IP data

V2.0 Page 29 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2 Perform downlink data transfer on DUT DUT receives ESM DATA TRANSPORT
message which contains IP data

2.3.1.4 Data Transfer with User Plane CIoT EPS Optimizations - Non IP PDN Type
Description
Data transfer via non-IP
Related core specifications
3GPP TS 23.401,3GPP TS 24.301, TS 36.211, TS 36.213
TS.39_2.4.2_REQ_001
Reason for test
Verify CAT-M1 and CAT-NB1 device can transport data use Non IP PDN Type with User
Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support Non IP PDN Type
DUT is in RRC_CONNECTED State.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT DUT sends ESM DATA TRANSPORT
message which contains Non IP data
2 Perform downlink data transfer on DUT DUT receives ESM DATA TRANSPORT
message which contains Non IP data

2.3.1.5 Data Transfer with Control Plane CIoT EPS Optimizations - SMS
Description
SMS message transfer
Related core specifications
3GPP TS 24.301, TS 23.401, 3GPP TS 23.040
Reason for test
Verify CAT-M1 and CAT-NB1 device can transport and receive SMS message with Control
Plane CIoT EPS Optimizations.
Initial configuration
DUT and Client 1 are configured with “Control Plane CIoT EPS Optimizations” in “Preferred
and Supported Network Behaviour”.
Client 1 indicates the same UE category as DUT.
DUT is in RRC_IDLE State.
Test procedure

V2.0 Page 30 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Send the SMS message from DUT to Client DUT sends Control Plane Service
1 Request message which contains SMS
message
SMS is successfully received on Client 1.
2 Send the SMS message from Client 1 to SMS is successfully received on DUT.
DUT

2.3.2 Suspend Resume

2.3.2.1 CAT-M1 Device Suspend-Resume procedure with User Plane CIoT EPS
Optimization
Description
CAT-M1 device could successfully perform the suspend-resume procedure. After resuming
the RRC connection the CAT-M1 device shall re-activate security and re-establish the DRB
connection
Related core specifications
GSMA TS.39_2.6.2_REQ_001 (Suspend)
GSMA TS.39_2.6.2_REQ_002 (Resume)
3GPP TS 36.331
Reason for test
To verify that CAT-M1 device could successfully perform the suspend and resume
procedure. After resuming the RRC connection the CAT-M1 device shall re-activate security
and re-establish the DRB connection.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”
DUT is Switched ON
DUT has DRB connection established
The NW is configured to support CAT-M1 and “User Plane CIoT EPS Optimizations”

Test procedure

V2.0 Page 31 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Trigger the NW to send an DUT releases RRC connection and moves
RRCConnectionRelease Message including into RRC_IDLE state. (DUT stores
the “resumeIdentity” and “release cause: resumeIdentity during RC connection
rrc-Suspend” release)
Trigger the DUT to send some user data in DUT transmits RRCConnectionResume
UL Request Message with “resumeIdentity”
and including information needed by the
eNodeB to access the DUT's stored AS
Context.

2 Security is fully resumed on DUT side

after reception and processing of
RRCConnectionResume Message.
Some EPS bearer can’t be resumed by
the NW, in that case eNB will reconfigure
the radio bearers.
UL Data from DUT is sent

Example message flow:

Direction
Step Message Comments
UE - NW
RRC: RRCConnectionRelease The NW transmits an
RRCConnectionRelease
1a <-- message including
“resumeIdentity” and “rrc-
Suspend” as releaseCause.
RRC: RRCConnectionResumeRequest DUT transmits an
RRCConnectionResumeRequ
est message including the
2a -->
“resumeIdentity” and “AS
security context” stored in step
1a
2b <-- RRC: RRCConnectionResume
2c --> RRC: RRCConnectionResumeComplete

2.3.2.2 CAT-NB1 Device Suspend-Resume procedure with User Plane CIoT EPS
Optimization
Description
CAT-NB1 device could successfully perform the suspend-resume procedure.
Related core specifications
GSMA TS.39_2.6.2_REQ_001
GSMA TS.39_2.6.2_REQ_002
3GPP TS 36.331
Reason for test

V2.0 Page 32 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

To verify that CAT-NB1 device could successfully perform the suspend and resume
procedure.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”
DUT is Switched ON
The NW is configured to support CAT-NB1 and “User Plane CIoT EPS Optimizations”
Test procedure

Step Test procedure Expected behaviour

1 Trigger the NW to send an DUT releases RRC connection and moves
RRCConnectionRelease-NB Message into RRC_IDLE state. (DUT stores
including the “resumeIdentity” and “release resumeIdentity during RC connection
cause: rrc-Suspend” release)
Trigger the DUT to send some user data in DUT transmits
UL RRCConnectionResumeRequest-NB
Message with “resumeIdentity” and
including information needed by the eNB to
2 access the DUT's stored AS Context.
Some EPS bearer can’t be resumed by the
network, in that case eNodeB will
reconfigures the radio bearers
UL Data from DUT is sent

Example message flow:

Direction
Step Message Comments
UE - NW
<-- RRC: RRCConnectionRelease-NB The NW transmits an
RRCConnectionRelease-NB
1a message including
“resumeIdentity” and “rrc-
Suspend” as releaseCause.
--> RRC: RRCConnectionResumeRequest-NB DUT transmits an
RRCConnectionResumeRequ
est-NB message including the
2a
“resumeIdentity” and “AS
security context” stored in step
1a
2b <-- RRC: RRCConnectionResume-NB
2c --> RRC: RRCConnectionResumeComplete-NB

V2.0 Page 33 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.3.3 Serving PLMN Rate Control / APN Rate Control

2.3.3.1 Serving PLMN Rate Control

Description
CAT-NB1 device could support Serving PLMN Rate Control.
Related core specifications
GSMA TS.39_2.7.1_REQ_001 (Serving PLMN Rate Control)
3GPP TS 23.401, 24.301
Reason for test
To verify that CAT-NB1 device could support Serving PLMN Rate Control .
Initial configuration
DUT is configured to support Serving PLMN Rate Control；
DUT is Switched OFF
DUT attach Procedure with Control Plane CIoT EPS
The NW is configured to support CAT NB1 and “Serving PLMN Rate Control ”
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT is in EMM-IDLE mode; set up RRC
connection and sends Attach Request
message indicating support of “Control
Plane CIoT EPS” together with PDN
CONNECTIVITY REQUEST Message.
2 Wait until the DUT sends Attach Complete DUT receive of ACTIVATE DEFAULT
message to NW， verify the DUT receive of EPS BEARER CONTEXT REQUEST
ACTIVATE DEFAULT EPS BEARER message from NW, which including
CONTEXT REQUEST message from NW, “serving PLMN rate control” parameter,
which including “serving PLMN rate control” such as：10 . （It indicate the maximum
parameter number of uplink ESM DATA
TRANSPORT messages including User
data container IEs , which indicate that the
DUT is allowed to send via a PDN
connection per 6 minute interval is 10 (see
3GPP TS 23.401)）.
3 DUT send the uplink user data. DUT send the uplink user data by ESM
DATA TRANSPORT message via the
control plan.
4 Verify the DUT limit the rate once the once the number of ESM DATA
number of ESM DATA TRANSPORT TRANSPORT message is more than the
message is more than the “serving PLMN “serving PLMN rate control” parameter,
rate control” parameter, to comply with the DUT can’t send the uplink user data.
serving PLMN policy provided by the
network.

V2.0 Page 34 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.3.3.2 APN Rate Control

Description
CAT-NB1 device could support APN Rate Control.
Related core specifications
GSMA TS.39_2.7.2_REQ_002 (APN Rate Control)
3GPP TS 24.008, 23.401 and 24.301
Reason for test
To verify that CAT-NB1 device could support APN Rate Control .
Initial configuration
DUT is configured to support APN Rate Control；
DUT is Switched OFF
DUT attach Procedure
The NW is configured to support APN Rate Control
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT is in EMM-IDLE mode; set up RRC
connection and sends Attach Request
message with PDN CONNECTIVITY
REQUEST Message. The PDN
CONNECTIVITY REQUEST Message
indicating support of “APN rate control
support indicator”.
2 Wait until the DUT sends Attach Complete DUT receive of ACTIVATE DEFAULT
message to NW， verify the DUT receive of EPS BEARER CONTEXT REQUEST
ACTIVATE DEFAULT EPS BEARER message from NW, which including “APN
CONTEXT REQUEST message from NW, rate control ” parameter, such as：10 . （
which including “APN rate control” It indicate the maximum allowed limit of
parameter uplink user data related to the
corresponding APN in accordance with
3GPP TS 23.401 .
3 DUT send the uplink user data. DUT send the uplink user data by ESM
DATA TRANSPORT message via the
control plan.
4 Verify the DUT limit the rate once the once the number of ESM DATA
number of ESM DATA TRANSPORT TRANSPORT message is more than the
message is more than the “APN rate “APN rate control” parameter, DUT can’t
control” parameter, to comply with the send the uplink user data.
APN rate control policy provided by the
network.

V2.0 Page 35 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.4 Mobility Performance

2.4.1 IDLE-Mode Mobility

2.4.1.1 CAT-M1 Device Cell Reselection Procedure

Description
CAT-M1 device performs Cell Reselection Procedure with CIoT EPS Optimizations when re-
selection criteria and ranking criteria are met.
Related core specifications
GSMA TS.39_2.5.1_REQ_001 (Cell Reselection)
3GPP TS 36.304, TS 36.300 and TS 36.331
Reason for test
To verify that CAT-M1 device could successfully perform Cell Reselection to new cell.
Initial configuration
DUT is configured with “CIoT EPS Optimizations” in “Preferred and Supported Network
Behaviour”
DUT is in RRC_IDLE state
Two EUTRAN cells (Cell 1 and Cell 2) are configured to support CAT M1 and “CIoT EPS
Optimizations”
Test procedure

Step Test procedure Expected behaviour

1 Change the radio conditions that Cell 1 DUT reselects to Cell 2 and starts to read
(serving cell) becomes unsuitable and Cell 2 System Information to check that “CIoT
(neighbour cell) becomes visible. EPS Optimizations are broadcasted.
2 Verify the DUT is attached to new Cell 2 DUT performs TAU procedure in Cell 2 and
releases RRC connection.

2.4.1.2 CAT-NB1 Device Intra-Frequency Cell Reselection

Description
CAT-NB1 device performs the cell reselection within the Intra-frequency NB-IoT cells under
RRC-Idle mode when serving cell becomes unsuitable.
Related core specifications
GSMA TS.39_2.5.1_REQ_001 (Cell Reselection)
3GPP TS 36.304, TS 36.300, and TS 36.331
Reason for test
To verify that CAT-NB1 device successfully performs the Cell Reselection within the Intra-
frequency NB-IoT cells under RRC-Idle mode.
Initial configuration
DUT is configured with “CIoT EPS Optimizations” in “Preferred and Supported Network
Behaviour”
DUT is in RRC_IDLE on serving Cell 1

V2.0 Page 36 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Two Intra-frequency cells (Cell 1 and Cell 2) are configured to support NB-IoT and “CIoT
EPS Optimizations”
The two cells (Cell 1 and Cell 2) have different tracking areas and neighbouring cell related
information available.
Test procedure

Step Test procedure Expected behaviour

1 Change the radio conditions that Cell 1 DUT reselects to Cell 2 and sends TAU to
(serving cell) becomes unsuitable (Srxlev < complete procedure. DUT releases RRC
SIntraSearchP) and Cell 2 (neighbour cell) connection and moves to RRC-IDLE
becomes visible (Srxlev > SIntraSearchP)

Example message flow:

Direction
Step Message Comments
UE - NW
1a --> RRC: RRCConnectionRequest-NB
1b <-- RRC: RRCConnectionSetup-NB
1c --> RRC: RRCConnectionSetupComplete-NB DUT transmits an
NAS: TRACKING AREA UPDATE REQUEST RRCConnectionSetupComplet
e-NB message to confirm the
successful completion of the
connection establishment and
a TRACKING AREA UPDATE
REQUEST message is sent to
update the registration of the
actual tracking area.
1d <-- RRC: DLInformationTransfer-NB
NAS: TRACKING AREA UPDATE ACCEPT
1e --> RRC: ULInformationTransfer-NB
NAS: TRACKING AREA UPDATE COMPLETE
1f <-- RRC: RRCConnectionRelease-NB NW transmits an
RRCConnectionRelease-NB
message to release RRC
connection and move to
RRC_IDLE.

2.4.1.3 CAT-NB1 Device Inter-Frequency Cell Reselection

Description
To verify that CAT-NB1 device successfully performs the Cell Reselection within the Inter-
frequency NB-IoT cells under RRC-Idle mode.
Related core specifications
GSMA TS.39_2.5.1_REQ_001 (Cell Reselection)
3GPP TS 36.304, TS 36.300, and TS 36.331
Reason for test

V2.0 Page 37 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

To verify that CAT-NB1 device successfully performs the Cell Reselection within the Inter-
frequency NB-IoT cells under RRC-Idle mode.
Initial configuration
DUT is configured with “CIoT EPS Optimizations” in “Preferred and Supported Network
Behaviour”
DUT is in RRC_IDLE on serving Cell 1
Two Inter-frequency cells (Cell 1 and Cell 2) are configured to support NB-IoT and “CIoT
EPS Optimizations”
The two cells (Cell 1 and Cell 2) have different tracking areas and neighboring cell related
information available.
Test procedure

Step Test procedure Expected behaviour

1 Change the radio conditions that Cell 1 DUT reselects to Cell 2 and sends TAU to
(serving cell) becomes unsuitable (Srxlev < complete procedure. DUT releases RRC
SnonIntraSearchP) and Cell 2 (neighbour cell) connection and moves to RRC-IDLE
becomes visible (Srxlev > SnonIntraSearchP).

Example message flow:

Direction
Step Message Comments
UE - NW
1a --> RRC: RRCConnectionRequest-NB
1b <-- RRC: RRCConnectionSetup-NB
1c --> RRC: RRCConnectionSetupComplete-NB DUT transmits an
NAS: TRACKING AREA UPDATE REQUEST RRCConnectionSetupComplet
e-NB message to confirm the
successful completion of the
connection establishment and
a TRACKING AREA UPDATE
REQUEST message is sent to
update the registration of the
actual tracking area.
1d <-- RRC: DLInformationTransfer-NB
NAS: TRACKING AREA UPDATE ACCEPT
1e --> RRC: ULInformationTransfer-NB
NAS: TRACKING AREA UPDATE COMPLETE
1f <-- RRC: RRCConnectionRelease-NB NW transmits an
RRCConnectionRelease-NB
message to release RRC
connection and move to
RRC_IDLE.

V2.0 Page 38 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.4.2 Connected Mode Mobility

2.4.2.1 CAT-M1 Device Handover Procedure with CIoT EPS Optimization

Description
CAT-M1 device performs the handover procedure with CIoT EPS Optimization.
Related core specifications
GSMA TS.39_2.5.1_REQ_002 (Handover)
3GPP TS 23.401, TS 36.300 and TS 36.331
Reason for test
To verify that CAT-M1 device could successfully perform the handover procedure with CIoT
EPS Optimization
Initial configuration
DUT is configured with “CIoT EPS Optimizations” in “Preferred and Supported Network
Behaviour”
DUT is in RRC_IDLE state
Two EUTRAN cells (Cell 1 and Cell 2) are configured to support CAT M1 and “CIoT EPS
Optimizations”
Test procedure

Step Test procedure Expected behaviour

1 Initiate Data transfer on DUT. (Amount of DUT enters RRC_CONNECTED and data
data should outlast HO procedure) transfer is ongoing.
2 Change the radio conditions that Cell 1 DUT transmits measurement reports when
(serving cell) becomes unsuitable and Cell 2 conditions are met and performs handover
(neighbour cell) becomes visible. to Cell 2. (RRCConnectionReconfiguration)
3 Verify that DUT performed the handover to DUT is in RRC_CONNECTED at Cell 2 and
Cell 2. the data transfer is ongoing

Example message flow:

Direction
Step Message Comments
UE - NW
2a <-- RRCConnectionReconfiguration
2b --> RRCConnectionReconfigurationComplete
2c --> MeasurementReport
2d <-- RRCConnectionReconfiguration
2e --> RRCConnectionReconfigurationComplete

2.4.2.2 CAT-NB1 Device Cell Redirection

Description
CAT-NB1 device completes redirection to another NB-IoT cell by leaving RRC-Connected
Mode to RRC-Idle Mode.

V2.0 Page 39 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Related core specifications

GSMA TS.39_2.5.1_REQ_001 (Cell Reselection)
3GPP TS 36.304, TS 36.300, and TS 36.331
Reason for test
To verify that CAT-M1 device could successfully complete redirection procedure to another
NB-IoT cell by leaving RRC-Connected Mode to RRC-Idle Mode.
Initial configuration
DUT is configured with “CIoT EPS Optimizations” in “Preferred and Supported Network
Behaviour”
DUT is in RRC_Connected on Cell 1
Two Inter-frequency cells (Cell 1 and Cell 2) are configured to support NB-IoT and “CIoT
EPS Optimizations”
The two cells (Cell 1 and Cell 2) have different tracking areas and neighbouring cell related
information available.
Cell 2 with the target frequency is in a good condition.
Test procedure

Step Test procedure Expected behaviour

1 Change the radio conditions that Cell 1 NW sends RRCConnectionRelease-NB
(serving cell) becomes unsuitable and NW message (IE redirectedCarrierInfo including
sends RRCConnectionRelease-NB carrierFreq-r13 of Cell 2)
DUT leaves RRC-Connected to RRC-IDLE
reselects to Cell 2 and sends TAU to
complete procedure. DUT releases RRC
connection and moves to RRC-IDLE

Example message flow:

Direction
Step Message Comments
UE - NW
1a <-- RRCConnectionRelease-NB NW transmits an
RRCConnectionRelease-NB
message (IE
redirectedCarrierInfo including
carrierFreq-r13 of Cell 2).
1b --> RRC: RRCConnectionRequest-NB
1c <-- RRC: RRCConnectionSetup-NB

V2.0 Page 40 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Direction
Step Message Comments
UE - NW
1d --> RRC: RRCConnectionSetupComplete-NB DUT transmits an
NAS: TRACKING AREA UPDATE REQUEST RRCConnectionSetupComplet
e-NB message to confirm the
successful completion of the
connection establishment and
a TRACKING AREA UPDATE
REQUEST message is sent to
update the registration of the
actual tracking area.
1e <-- RRC: DLInformationTransfer-NB
NAS: TRACKING AREA UPDATE ACCEPT
1f --> RRC: ULInformationTransfer-NB
NAS: TRACKING AREA UPDATE COMPLETE
1g <-- RRC: RRCConnectionRelease-NB NW transmits an
RRCConnectionRelease-NB
message to release RRC
connection and move to
RRC_IDLE.

2.5 Device Capabilities

2.5.1 CAT-NB1 Uplink Transmission Capability – 3.7kHz (Single-tone)

Description
For CAT-NB1 device, uplink transmission capability (3.75kHz, single-tone) needs to be
verified.
Related core specifications
3GPP TS 36.211, TS 36.331.
Reason for test
Verify CAT-NB1 device can support single-tone transmission with 3.75kHz subcarrier
spacing.
Initial configuration
NB-IoT eNodeB is configured to only support single-tone transmission with 3.75kHz
subcarrier spacing.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Powers on DUT DUT successfully access the cell
2 Perform uplink data transfer Using logging tool to verify DCI Format N0
indicate 3.75kHz/single-tone.
Uplink data is successfully transferred

V2.0 Page 41 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

2.5.2 CAT-NB1 Uplink Transmission Capability - 15kHz (Single-tone)

Description
For CAT-NB1 device, uplink transmission capability (15kHz, single-tone) needs to be
verified.
Related core specifications
3GPP TS 36.211, TS 36.331.
Reason for test
Verify CAT-NB1 device can support single-tone transmission with 15kHz subcarrier spacing.
Initial configuration
NB-IoT eNodeB is configured to only support single-tone transmission with 15kHz subcarrier
spacing.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Powers on DUT DUT successfully access the cell
2 Perform uplink data transfer Using logging tool to verify DCI Format N0
indicate 15kHz/single-tone.
Uplink data is successfully transferred

2.5.3 CAT-NB1 Uplink Transmission Capability - 15kHz (Multi-tone)

Description
For CAT-NB1 device, uplink transmission capability (15kHz, multi-tone) needs to be verified.
Related core specifications
3GPP TS 36.211, TS 36.331.
Reason for test
Verify CAT-NB1 device can support multi-tone transmission with 15kHz subcarrier spacing.
Initial configuration
NB-IoT eNodeB is configured to only support multi-tone transmission with 15kHz subcarrier
spacing.
Scenario A：
NB-IoT eNodeB schedules 3 subcarriers for DUT in multi-tone transmission. (3 tones)
Scenario B：
NB-IoT eNodeB schedules 6 subcarriers for DUT in multi-tone transmission. (6 tones)
Scenario C:
NB-IoT eNodeB schedules 12 subcarriers for DUT in multi-tone transmission. (12 tones)
This test requires logging tools.

V2.0 Page 42 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Test procedure
Step Test procedure Expected behaviour
1 Powers on DUT DUT successfully access the cell.
2 Perform uplink data transfer Using logging tool to verify DCI Format
N0 indicate 15kHz/Multi-tone.
Scenario A: Duration of RU is 4ms
Scenario B: Duration of RU is 2ms
Scenario C: Duration of RU is 1ms
Uplink data is successfully transferred

3 Device Performance in Enhanced Coverage

3.1 Registration

3.1.1 Attach Performance with Control Plane CIoT EPS Optimizations

Description
Attach performance under different coverage level
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.331
TS.39_2.2.2_REQ_001
TS.39_3.1.2_REQ_001
Reason for test
Verify attach performance of CAT-M1 and CAT-NB1 device in enhanced coverage with
Control Plane CIoT EPS Optimizations.
Initial configuration
DUT and Reference 1 are configured with “Control Plane CIoT EPS Optimizations” in
“Preferred and Supported Network Behaviour”. DUT and Reference 1 are Switched OFF
Reference 1 indicating the same UE category is tested in the same location as DUT.
For CAT-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT and Reference 1 Record the time difference between
transmission of first Random Access
Preamble and Attach Complete message.
Verify the DUT’s delay performance is
comparable to the Reference 1’s delay
performance (average value of 10 times is

V2.0 Page 43 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

no more than 10% worse ).
2 Repeat step 1 10 times under each Verify the DUT’s attach success ratio is
coverage level. comparable to the Reference 1’s success
ratio under each coverage level.

3.1.2 Attach Performance with User Plane CIoT EPS Optimizations

Description
Attach performance under different coverage level
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.331
TS.39_2.2.2_REQ_001
TS.39_3.1.2_REQ_001
Reason for test
Verify attach performance of CAT-M1 and CAT-NB1 device in enhanced coverage with User
Plane CIoT EPS Optimizations.
Initial configuration
DUT and Reference 1 are configured with “User Plane CIoT EPS Optimizations” in
“Preferred and Supported Network Behaviour”.
DUT and Reference 1 are Switched OFF
Reference 1 indicating the same UE category is tested in the same location as DUT.
For CAT-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT and Reference 1 Record the time difference between
transmission of first Random Access
Preamble and Attach Complete message.
Verify the DUT’s delay performance is
comparable to the Reference 1’s delay
performance (average value of 10 times is
no more than 10% worse).
2 Repeat step 1 10 times under each Verify the DUT’s attach success ratio is
coverage level. comparable to the Reference 1’s success
ratio under each coverage level.

V2.0 Page 44 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

3.2 Paging

3.2.1 Paging performance under different coverage level

Description
Paging performance under different coverage level
Related core specifications
3GPP TS 36.331
Reason for test
Verify paging performance of CAT-M1 and CAT-NB1 device under different coverage level.
Initial configuration
The NW supports the paging procedure when downlink data request is generated.
Reference 1 indicating the same UE category is tested in the same location as DUT. For
Cat-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
eDRX is disabled on DUT and Reference 1.
DUT and Reference 1 are in RRC_IDLE.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Downlink data request is sent to DUT None

and Reference 1
2 Verify the DUT successfully establishes Record the time difference between
RRC Connection. reception of paging message and
transmission of
RRCConnetctionSetupComplete
message.
Verify the DUT’s delay performance is
comparable to the Reference 1’s delay
performance (no more than 10% worse).
3 Repeat step 1-2 10 times under each Verify the DUT’s paging success ratio is
coverage level. comparable to the Reference 1’s success
ratio under each coverage level

3.2.2 Paging with eDRX cycle under different coverage level

Description
Performance of paging with eDRX cycle under different coverage level
Related core specifications
3GPP TS 36.331
Reason for test

V2.0 Page 45 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Verify paging performance of CAT-M1 and CAT-NB1 device under different coverage level
when eDRX cycle is configured.
Initial configuration
The NW supports the paging procedure when downlink data request is generated.
Reference 1 indicating the same UE category is tested in the same location as DUT.
For CAT-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
eDRX is enabled on DUT and Reference 1 with similar configuration.
DUT and Reference 1 are in RRC_IDLE.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Downlink data request is sent to DUT Extended DRX parameters is included in
and Reference 1 downlink data request.
2 Verify the DUT and Reference 1 DUT’s and Reference 1 are in RRC-
successfully establishes RRC Connection Connected mode.
3 Repeat step 1-2 10 times under each Verify the DUT’s paging success ratio is
coverage level. comparable to the Reference 1’s success
ratio under each coverage level

3.3 Data Transfer and Throughput

3.3.1 Data Transfer and Throughput with Control Plane CIoT EPS
Optimizations - IP PDN Type
Description
Data transfer performance via IP
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.211, TS 36.213
TS.39_3.2.2_REQ_001, TS.39_3.2.2_REQ_003
Reason for test
Verify data transfer performance of CAT-M1 and CAT-NB1 device use IP PDN Type with
Control Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support IP PDN Type
DUT is in RRC_CONNECTED State.
Reference 1 indicating the same UE category is tested in the same location as DUT.

V2.0 Page 46 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

For CAT-NB1 device, performance under coverage level 0/1/2 is tested.

For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT and Verify the DUT’s uplink data throughput is
Reference 1 for 60s comparable to the Reference 1’s
throughput (no more than 10% worse).
2 Perform downlink data transfer on DUT and Verify the DUT’s downlink data throughput
Reference 1 for 60s is comparable to the Reference 1’s
throughput (no more than 10% worse).
3 Repeat step 1-2 10 times under each Verify the DUT has comparable data
coverage level. performance to the Reference 1 under
each coverage level

3.3.2 Data Transfer and Throughput with Control Plane CIoT EPS
Optimizations - Non IP PDN Type
Description
Data transfer performance via non-IP
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.211, TS 36.213
TS.39_3.2.2_REQ_001, TS.39_3.2.2_REQ_003
Reason for test
Verify data transfer performance of CAT-M1 and CAT-NB1 device use Non IP PDN Type
with Control Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “Control Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support Non IP PDN Type
DUT is in RRC_CONNECTED State.
Reference 1 indicating the same UE category is tested in the same location as DUT.
For CAT-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT and Verify the DUT’s uplink data throughput is
comparable to the Reference 1’s

V2.0 Page 47 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Reference 1 for 60s throughput (average value of 10 times is

no more than 10% worse).
2 Perform downlink data transfer on DUT and Verify the DUT’s downlink data throughput
Reference 1 for 60s is comparable to the Reference 1’s
throughput (average value of 10 times is
no more than 10% worse).
3 Repeat step 1-2 10 times under each Verify the DUT has comparable data
coverage level. performance to the Reference 1 under
each coverage level

3.3.3 Data Transfer and Throughput with User Plane CIoT EPS Optimizations
- IP PDN Type
Description
Data transfer performance via IP
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.211, TS 36.213
TS.39_3.2.2_REQ_001, TS.39_3.2.2_REQ_003
Reason for test
Verify data transfer performance of CAT-M1 and CAT-NB1 device use IP PDN Type with
User Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support IP PDN Type
DUT is in RRC_CONNECTED State.
Reference 1 indicating the same UE category is tested in the same location as DUT.
For CAT-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT and Verify the DUT’s uplink data throughput is
Reference 1 for 60s comparable to the Reference 1’s
throughput (average value of 10 times is
no more than 10% worse).
2 Perform downlink data transfer on DUT and Verify the DUT’s downlink data throughput
Reference 1 for 60s is comparable to the Reference 1’s
throughput (average value of 10 times is
no more than 10% worse).
3 Repeat step 1-2 10 times under each Verify the DUT has comparable data
coverage level. performance to the Reference 1 under

V2.0 Page 48 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

each coverage level

3.3.4 Data Transfer and Throughput with User Plane CIoT EPS Optimizations
- Non IP PDN Type
Description
Data transfer performance via non-IP
Related core specifications
3GPP TS 23.401, TS 24.301, TS 36.211, TS 36.213
TS.39_3.2.2_REQ_001, TS.39_3.2.2_REQ_003
Reason for test
Verify data transfer performance of CAT-M1 and CAT-NB1 device use Non IP PDN Type
with User Plane CIoT EPS Optimizations.
Initial configuration
DUT is configured with “User Plane CIoT EPS Optimizations” in “Preferred and Supported
Network Behaviour”.
DUT is configured to support Non IP PDN Type
DUT is in RRC_CONNECTED State.
Reference 1 indicating the same UE category is tested in the same location as DUT.
For CAT-NB1 device, performance under coverage level 0/1/2 is tested.
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
Test procedure

Step Test procedure Expected behaviour

1 Perform uplink data transfer on DUT and Verify the DUT’s uplink data throughput is
Reference 1 for 60s comparable to the Reference 1’s
throughput (average value of 10 times is
no more than 10% worse).
2 Perform downlink data transfer on DUT and Verify the DUT’s downlink data throughput
Reference 1 for 60s is comparable to the Reference 1’s
throughput (average value of 10 times is
no more than 10% worse).
3 Repeat step 1-2 10 times under each Verify the DUT has comparable data
coverage level. performance to the Reference 1 under
each coverage level

3.4 Mobility Performance

3.4.1 Idle Mode Mobility Performance – Cell Reselection

Description
Cell reselection performance in RRC-IDLE mode

V2.0 Page 49 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Related core specifications

GSMA TS.39_2.5.1_REQ_001
3GPP TS 36.300, TS 36.304, TS 36.331
Reason for test
To verify cell reselection performance of CAT-M1 and CAT-NB1 device under RRC-IDLE
mode in mobility state.
Initial configuration
A number of cells(NB-IoT/ E-UTRAN) is available along the test route.
Reference 1 indicates the same UE category as DUT.
DUT and Reference 1 are moving in the same test route at the same speed.
DUT and Reference 1 are in RRC_IDLE.
This test requires logging tools.
Test procedure

Step Test procedure Expected behaviour

1 Drive along the test route, Verify the DUT’s cell reselection success
ratio is comparable to the Reference 1’s cell
reselection success ratio. (no more than
10% worse).

3.4.2 Connected Mode Mobility Performance

3.4.2.1 Cat-M1 Device Connected Mode Mobility Performance - Handover

Description
Handover performance of CAT-M1 device
Related core specifications
GSMA TS.39_2.5.1_REQ_002
3GPP TS 36.300, TS 36.331
Reason for test
To verify handover performance of CAT-M1 device under RRC-CONNECTED mode in
mobility state.
Initial configuration
A number of E-UTRAN cells is available along the test route.
Reference 1 indicates the same UE category as DUT.
DUT and Reference 1 are moving in the same test route at the same speed.
DUT and Reference 1 are in RRC_CONNECTED state.
This test requires logging tools.
Test procedure

V2.0 Page 50 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

1 Drive along the test route. Continuously Verify the DUT’s handover success ratio is
perform uplink data transfer on DUT and comparable to the Reference 1’s handover
Reference 1 success ratio. (not more than 10% worse).
Verify the DUT’s uplink data throughput is
comparable to the Reference 1’s
throughput (no more than 10% worse).

4 Power Optimized Operation

This section should be read in conjunction with TS.39 v2.0, MIoT Requirements document.
The Conformance requirements contained with Section 4 of that document apply.

4.1 PSM Operation

4.1.1 PSM Request, Activation and Modification

Description
The DUT successfully requests PSM during attach by adding T3324 into ATTACH
REQUEST. The DUT requests different timer values during TAU when modified by the User
or Application.
Related core specifications
GSMA TS.39_4.1_REQ_001
GSMA TS.39_4.1_REQ_005
3GPP TS 23.682, TS 23.401, TS 24.301, TS 24.008
Reason for test
To verify that CAT-M1 or CAT-NB1 device requests and activated PSM. To verify that DUT
initiates a TAU procedure caused by change of PSM usage conditions (change in DUT
configuration).
Initial configuration
DUT is configured to use Power Saving Mode
DUT is configured with T3324 value (e.g. 2 minutes)
DUT is switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT sends Attach Request containing
“T3324 Value” in order to request PSM.
DUT responds ATTACH ACCEPT message
from NW with ATTACH COMPLETE
message and releases the connection
Change the value of T3324 (e.g. to 1 minute) DUT initiates TRACKING AREA UPDATE
in DUT REQUEST including the new value for
2
T3324.
DUT responds TAU ACCEPT message

V2.0 Page 51 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Step Test procedure Expected behaviour

from NW with TAU COMPLETE message
and releases the connection

4.1.2 MT Data in PSM State

Description
CAT-M1 and CAT-NB1 device monitor Paging message and receive MT user data when
T3324 Timer running and then enter PSM again when T3324 timer expires.
Related core specifications
GSMA TS.39_4.1_REQ_001
3GPP TS 23.682, TS 24.301 and TS 24.008
Reason for test
To verify that CAT-M1 or Cat-NB1 device successfully monitor Paging message and receive
MT user data when T3324 Timer running and then enter PSM again when T3324 timer
expires.
Initial configuration
DUT is configured to use Power Saving Mode
DUT is configured with T3324 value (e.g. 2 minutes)
DUT is switched off
Test procedure
Step Test procedure Expected behaviour
1 Switch on DUT DUT sends Attach Request containing
“T3324 Value” in order to request PSM.
DUT responds ATTACH ACCEPT message
from NW with ATTACH COMPLETE
message and releases the connection
Initiate MT user date before T3324 expires DUT responds to paging message,
2 establishes connection and receive MT
data
Stop MT data. DUT releases the connection, enters in idle
3
state and starts T3324 timer.
Initiate MT user date after T3324 expires DUT is still in PSM and does not response
4
to MT data.

4.1.3 MO Data in PSM State

Description
CAT-M1 and CAT-NB1 device deactivate PSM at any time for the transfer of mobile
originated user data.
Related core specifications
GSMA TS.39_4.1_REQ_001
GSMA TS.39_4.1_REQ_007
3GPP TS 23.682, TS 24.301 and TS 24.008

V2.0 Page 52 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Reason for test

To verify that CAT-M1 or CAT-NB1 device successfully deactivate PSM at any time for the
transfer of mobile originated user data.
Initial configuration
DUT is configured to use Power Saving Mode
DUT is configured with T3324 value (e.g. 2 minutes)
DUT is switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT sends Attach Request containing
“T3324 Value” in order to request PSM.
DUT responds ATTACH ACCEPT message
from NW with ATTACH COMPLETE
message and releases the connection
2 Wait until T3324 expires DUT enters PSM after T3324 expires
Attempt to page DUT to verify PSM state DUT is in PSM and does not response to
3
MT data.
Initiate MO user date DUT shall deactivate PSM , establish
4
connection and send MO data

4.1.4 Periodic Tracking Area Update

Description
CAT-M1 and CAT-NB1 device performs a Periodic Tracking Area Update procedure after
the expiry of the T3412/T3312 timer when PSM is activated.
Related core specifications
GSMA TS.39_4.1_REQ_001
3GPP TS 23.682, TS 24.301 and TS 24.008
Reason for test
To verify that CAT-M1 or CAT-NB1 device successfully performs a Periodic Tracking Area
Update procedure after the expiry of the T3412/T3312 timer when PSM is activated.
Initial configuration
DUT is configured to use Power Saving Mode
DUT is configured with T3324 value (e.g.2 minutes)
DUT is switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT sends Attach Request containing
“T3324 Value” in order to request PSM.
NW sends ATTACH ACCEPT message

V2.0 Page 53 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

that contains the “T3324 Value” for PSM

and “T3412 Value” for periodic TAU
DUT responds with ATTACH COMPLETE
message and releases the connection
Wait until T3324 and T3412 expire DUT enters PSM after T3324 expires.
After the expiry of T3412, DUT sends a
TAU REQUEST message including “T3324
value” IE.
The network responds to the DUT with TAU
2 ACCEPT message that contains the “T3324
value”
DUT completes the TAU procedure by
sending TAU COMPLETE message.
DUT releases the connection and enters in
idle state.
3 Wait until T3324 expires. DUT enters PSM after T3324 expires
Attempt to page DUT to verify PSM state DUT is in PSM and does not response to
4
MT data.

4.1.5 Periodic Tracking Area Update, T3412

Description
CAT-M1 and Cat-NB1 device could accept T3412 value from NW.
Related core specifications
GSMA TS.39_2.2.2_REQ_001 (Attach)
GSMA TS.39_2.3.2_REQ_001 (Device Capabilities)
GSMA TS.39_4.1_REQ_006 (Accept T3412 from NW)
3GPP TS 23.682, TS 24.301 and TS 24.008
Reason for test
To verify that CAT-M1 or Cat-NB1 device accepts T3412 value from NW that is different
from pre-configured value.
Initial configuration
DUT is configured to use Power Saving Mode
DUT is configured with T3324 value (e.g..2 minutes)
DUT is configured with preferred T3412 value (different from NW; default 54min), value e.g.
4 minutes)
DUT is switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT sends Attach Request containing
“T3324 Value” and a preferred “T3412
Value” in order to request PSM.
The ATTACH ACCEPT message of NW

V2.0 Page 54 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

contains different T3412 value.

DUT accepts new value for T3412 in
ATTACH COMPLETE MESSAGE
2 Wait until DUT is in IDLE and T3324 expires DUT enters PSM after T3324 expires
Wait until T3412 expires and verify that the DUT initiates TAU after expiry of T3412
3
DUT initiates Tracking Area update. (NW value)

4.1.6 Reduced Current Drain in PSM

Description
CAT-M1 and CAT-NB1 device support a reduced current drain when in Power Saving Mode.
Related core specifications
GSMA TS.39_4.1_REQ_003
3GPP TS 23.682, TS 24.301 and TS 24.008
Reason for test
To verify that CAT-M1 or CAT-NB1 device support a reduced current drain when in PSM.
Initial configuration
DUT is configured to disable Power Saving Mode
DUT is configured with T3324 value (e.g. 2 minutes)
DUT battery is replaced with “dummy battery” that is connected to a combined DC power
source and current measurement device.
DUT is switched off
All other radios (e.g. Wi-Fi, BT, etc.) in DUT are switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT registers to the NW
Wait 3 min after DUT has completed DUT is registered and in IDLE mode
2
registration.
Record a minimum of 120 samples over a ‘-
continuous 30 minute period, using
3
ammeters or automated power monitors if
available.
Calculate the average current drain from ‘-
4 the measured samples, denoted by
IPSM_Disabled.
Configure the DUT to use PSM with timer ‘-
5 T3412 set to at least 30 minutes. Switch off
the DUT.
Switch on DUT and wait 3 minutes after DUT sends ATTACH REQUEST
6 DUT has completed registration containing “T3324 Value” in order to
request PSM.
7 In PSM mode, record a minimum of 120 ‘-

V2.0 Page 55 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

samples over a continuous 30 minute

period, using ammeters or automated
power monitors if available
Calculate the average current drain from The current drain in PSM (IPSM_Enabled)
the measured samples, denoted by should be several orders of magnitude
8
IPSM_Enabled lower than the one in idle mode
(IPSM_Disabled)

4.1.7 Periodic Tracking Area Update Power Consumption Performance

Description
Power consumption performance of periodic tracking area update with CAT-NB1 and CAT-
M1

Related core specifications

GSMA TS.39_4.1_REQ_011
Reason for test
To verify the power consumption performance of periodic tracking area update with CAT-
NB1 and CAT-M1 in different coverage (normal coverage and enhance coverage).

Initial configuration
The DUT battery is replaced with the “dummy battery”.
The dummy battery is connected to a combined DC power source and current measurement
device.
The DC power source is configured to maintain a voltage equal to the Nominal Battery
Voltage across the dummy battery terminals.
DUT is powered off.
All other radio's (WiFi/BT etc) in the device are switched off. DUT is configured to use Power
Saving Mode, with sleep timer (T3412 extended) set to 4 hours (for CAT-M1) or 12 hours(for
Cat-NB1).

V2.0 Page 56 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT initiates the Attach procedure.

2 Wait until DUT enters PSM. DUT has completed the Attach procedure
and releases the connection, DUT enters
in idle state, DUT enters PSM after T3324
expires, check by attempting to page the
DUT
3 After the expiry of the T3412 extended Record the TAU procedure, from
timer, DUT deactivate PSM, establish transmission of first Random Access
connection and completes the TAU Preamble to TRACKING AREA UPDATE
procedure. ACCEPT message/ or TRACKING AREA
Record the power consumption of TAU UPDATE COMPLETE(if GUTI allocated)
procedure in different coverage(normal message, denoted by PROCEDURETAU.
coverage and enhance coverage). Record the average current of
PROCEDURETAU, denoted by ITAU.
Record the time interval of
PROCEDURETAU, denoted by TTAU.
Calculate and record the power
consumption of PROCEDURETAU, denote
by POWERTAU, POWERTAU(milliwatt
hour)=Voltage(volt)×I
TAU(milliampere)×T TAU(second)/3600.

4.2 I-eDRX Operation

4.2.1 eDRX Request, Activation and Modification

Description
The DUT successfully requests eDRX during attach by adding the “Extended DRX
parameters” IE into ATTACH REQUEST. The DUT requests different timer values during
TAU when modified by the User or Application.
Related core specifications
TS.39_4.1_REQ_002
TS.39_4.1_REQ_008
TS.39_4.1_REQ_009
3GPP TS 23.682, TS 23.401, TS 24.301, TS 24.008
Reason for test
To verify that the DUT could successfully request eDRX during attach and monitor Paging
according to eDRX cycle and PTW (except EC-GSM). To verify that DUT initiates a TAU
procedure caused by change of eDRX usage conditions (change in DUT configuration).
Initial configuration
DUT is configured to use eDRX

V2.0 Page 57 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

DUT is configured with the “Extended DRX parameters” IE (e.g. The “Paging Time Window”
is set to 5.12s and the “eDRX value” is set to 20.48s)
DUT is switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT initiates the Attach procedure by
sending the “Attach Request” message that
contains the “Extended DRX parameters”
IE.
The network responds to the DUT with
“Attach Accept” message that contains the
“Extended DRX parameters” to indicate the
eDRX cycle and PTW (except EC-GSM).
DUT completes the Attach procedure by
sending the “Attach Complete” message.
DUT releases the connection.
2 Initiate MT user data the network sends Paging message.
DUT responds to the Paging and receives
the MT data
Change the value of “Extended DRX DUT initiates TRACKING AREA UPDATE
Parameter” IE (e.g. the “eDRX value” is set REQUEST including the new value for the
to122.88s) in DUT “eDRX value” after the expiry of T3412
3 timer.
DUT responds TAU ACCEPT message
from NW with TAU COMPLETE message
and releases the connection

4.2.2 Power Consumption in Idle State with eDRX

Description
Power Consumption performance of CAT-M1 and CAT-NB1 device.
Related core specifications
TS.39_4.1_REQ_002
TS.39_4.1_REQ_008
TS.39_4.1_REQ_009
TS.39_4.1_REQ_010
3GPP TS 23.682, TS 24.301 and TS 24.008
Reason for test
To measure the power consumption performance of CAT-M1 and CAT-NB1 device as eDRX
cycle increases.
Initial configuration
DUT is configured to enable eDRX

V2.0 Page 58 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

DUT is configured with the “Extended DRX parameters” IE. The “Paging Time Window” and
I-DRX cycle are set to static value, while the eDRX cycle is set to three levels, the level 1 is
below 1 minute, such as 20.48s, the level 2 is between 1 and 5 minutes such as 122.88s,
and the level 3 is greater than 10 minutes such as 655.36s. The choose of eDRX cycle
values depend on the actual network deployment.
Idle mode extended DRX is allowed in the serving cell. The periodic tracking area update
timer “T3412 value” is set longer than the test execution time.
DUT battery is replaced with “dummy battery” that is connected to a combined DC power
source and current measurement device.
Reference 1 indicating the same UE category has the same eDRX configuration as DUT.
DUT is switched off.
All other radios (e.g. Wi-Fi, BT, etc.) in DUT are switched off.
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT DUT registers to the NW
2 Wait until DUT enters the eDRX mode. DUT is registered and in eDRX mode,
Record the average current of at least one Output the value of IeDRX1/ IPTW1/Isleeping1. The
eDRX cycle over a continuous max{5 minute, currents of DUT are comparable to the
one eDRX cycle} period, denoted by currents of Reference 1.
IeDRX1;record the average current during
3
PTW, denoted by IPTW1;record the average
current of eDRX sleeping time, denoted by
Isleeping1.using ammeters or automated power
monitors if available.
Change the value of “Extended DRX
4
Parameter” IE to level 2 in DUT
Repeat step 1-3, denote as IeDRX2/ IPTW2/ Output the value of IeDRX2/ IPTW2/ Isleeping2.
6 Isleeping2 The currents of DUT are comparable to the
currents of Reference 1.
Change the value of “Extended DRX
7
Parameter” IE to level 3 in DUT
Repeat step 1-3, denote as IeDRX3/ IPTW3/ Output the value of IeDRX3/ IPTW3/ Isleeping3.
8 Isleeping3 The currents of DUT are comparable to the
currents of Reference 1.

4.3 Data transmission power consumption

4.3.1 CAT-M1 Device Uplink Transmission Power Consumption

Description
UL data transmission power consumption of CAT-M1 device in different coverage levels.
Related core specifications
TS.39_2.4.2_REQ_001

V2.0 Page 59 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

TS.39_4.1_REQ_011
3GPP TS 36.211, TS 36.331
Reason for test
To measure the UL transmission power consumption of CAT-M1 device in different coverage
level.
Initial configuration
For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
Reference 1 indicating the same UE category is tested in the similar environment as DUT.
DUT battery is replaced with “dummy battery” that is connected to a combined DC power
source and current measurement device.
DUT is switched off.
All other radios (e.g. Wi-Fi, BT, etc.) in DUT are switched off.
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT and Reference 1 DUT and Reference 1 registers to the NW
Wait until DUT and Reference 1 enters the DUT and Reference 1 is in standby mode,
2
standby mode.
Start power consumption measurement on Record DUT’s and Reference 1 transmit
DUT and Reference 1: power and average current.
3 -Trigger consecutive uplink data transmission
in UDP layer for 3 minutes.
-Record the average current
Repeat step 1-3 under different coverage The average current of DUT under each
4 level. coverage level is comparable to the result
for Reference 1;

4.3.2 CAT-NB1 Device Uplink Transmission Power Consumption

Description
UL data transmission power consumption of CAT-NB1 device in different coverage level can
meet expectations.
Related core specifications
TS.39_2.4.2_REQ_001
TS.39_4.1_REQ_011
3GPP TS 36.211, TS 36.331
Reason for test
To measure the UL transmission power consumption of CAT-NB1 device in different
coverage level.
Initial configuration

V2.0 Page 60 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Power consumption performance of Cat-NB1 device under coverage level 0/1/2 is tested.
Sub-carrier spacing of service cell support 15kHz single-tone, 15KHz multi-tone (3/6/12
tones), 3.75kHz single-tone.
Reference 1 indicating the same UE category is tested in the similar environment as DUT.
DUT battery is replaced with “dummy battery” that is connected to a combined DC power
source and current measurement device.
DUT is switched off
All other radios (e.g. Wi-Fi, BT, etc.) in DUT are switched off
Test procedure

Step Test procedure Expected behaviour

1 Serving cell is configured to support 3.75kHz The service cell set up successfully
sub-carrier spacing.
2 Switch on DUT and Reference 1 DUT registers to the NW
3 Wait until DUT enters the standby mode. DUT is registered and in standby mode,
Start power consumption measurement on Record DUT’s transmit power and average
DUT and Reference 1: current.
4 -Trigger consecutive uplink data transmission
in UDP layer for 3 minutes.
-Record the average current
Repeat step 2-4 under different coverage The average current of DUT under each
5 level. coverage level is comparable to the result
for Reference 1
The Sub-carrier spacing is configured to The average current of DUT under each
6 support 15kHz ST, Repeat step 2-5 coverage level is comparable to the result
for Reference 1
The Sub-carrier spacing is configured to The average current of DUT under each
7 support 15kHz MT, Repeat step 2-5 coverage level is comparable to the result
for Reference 1

4.3.3 Downlink Transmission Power Consumption

Description
DL data transmission power consumption of CAT-M1 and CAT-NB1 device in different
coverage can meet expectations.
Related core specifications
TS.39_2.4.2_REQ_001
TS.39_4.1_REQ_011
3GPP TS 36.211, TS 36.331
Reason for test
To measure the DL transmission power consumption of CAT-M1 and CAT-NB1 device in
different coverage.
Initial configuration

V2.0 Page 61 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

For CAT-NB1 device, performance under coverage level 0/1/2 is tested.

For CAT-M1 device supporting CE mode A, performance under coverage level 0/1 is tested.
For CAT-M1 device supporting CE mode B, performance under coverage level 0/1/2/3 is
tested.
Reference 1 indicating the same UE category is tested in the similar environment as DUT.
DUT battery is replaced with “dummy battery” that is connected to a combined DC power
source and current measurement device.
DUT is switched off
All other radios (e.g. Wi-Fi, BT, etc.) in DUT are switched off
Test procedure

Step Test procedure Expected behaviour

1 Switch on DUT and Reference 1 DUT registers to the NW
2 Wait until DUT enters the standby mode. DUT is registered and in standby mode,
Start power consumption measurement on The average current of DUT is comparable
DUT and Reference 1: to the result for Reference 1
3 -Trigger consecutive downlink data
transmission in UDP layer for 3 minutes.
-Record the average current
Repeat step 1-3 under different coverage The average current of DUT under each
4 level. coverage level is comparable to the result
for Reference 1

5 Service Layer

5.1 oneM2M
The oneM2M Service Layer interface test case SHALL follow the test case defined in the
following oneM2M Specifications:
 TS-0013 - Interoperability_Testing [5]:

 RemoteCSE Management in Clause 8.1.2

 Application Entity Registration in Clause 8.1.3
 Container Management in Clause 8.1.4

 TS-0017 - Implementation Conformance Statements [6]

5.2 LwM2M
The LwM2M standard provides service enabler to the service layer, as part of the
simplification needed for the IoT actors. It shall follow the test case defined in the LwM2M
Test Specifications:
 OMA-ETS-LightweightM2M-V1_0_1 [4]

 Application Data Container Management in Clause 6.1.6

V2.0 Page 62 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

6 USIM/eUICC OTA
UICC and USIM device interface test cases SHALL follow the test cases defined in
documents [2] and [3] referenced in Section 1.4.

7 USIM Toolkit
USIM ToolKit device interface test cases SHALL follow the test cases defined in document
[3], referenced in Section 1.4.

8 Antenna Performance
It is expected that Antenna Performance in a free space environment within relevant bands
and areas will be compliant with 3GPP and CTIA specifications, 3GPP TS.34.114 [10],
TS.37.544 [11] and CTIA, OTA Test Plan v 3.6 [12] or later versions of these documents
when available.

Test cases will be agreed with Operators and Manufacturers on a case by case basis.

9 Device Management (LwM2M)

LWM2M test cases SHALL follow the test cases defined in document [4], referenced in
Section 1.4

V2.0 Page 63 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

10 Mapping of Test Cases to Requirements

MioT Requirement Test Case Comments
Requirements
Document
Section
2 Basic TS.39_2.1.2_REQ_001 2.1.6 (CAT-NB1)
Operation (Cell selection) 2.1.7 (CAT-NB1)
2.1.9 (CAT-NB1)
TS.39_2.1.2_REQ_002 EC-GSM-IoT Test Cases to be
(Cell Selection EC-GSM-IoT) defined when Manufacturer
support is available.
TS.39_2.2.2_REQ_001 2.1.1 (CAT-M1)
(Attach) 2.1.2 (CAT-M1)
2.1.3 (CAT-M1)
2.1.4 (CAT-NB1)
2.1.5 (CAT-NB1)
2.1.6 (CAT-NB1)
2.1.7 (CAT-NB1)
2.1.8 (CAT-NB1)
2.1.9 (CAT-M1 & CAT-NB1)
3.1.1 (CAT-M1 & CAT-NB1)
3.1.2 (CAT-M1 & CAT-NB1)
4.1.5 (CAT-M1 & CAT-NB1)
TS.39_2.2.2_REQ_002 2.1.10 (CAT-M1 & CAT-NB1)
(Detach)
TS.39_2.2.2_REQ_003 EC-GSM-IoT Test Cases to be
(Attach EC-GSM-IoT) defined when Manufacturer
support is available.
TS.39_2.2.2_ REQ_004 EC-GSM-IoT Test Cases to be
(Detach EC-GSM-IoT) defined when Manufacturer
support is available.
TS.39_2.2.2_REQ_005 2.1.9 CAT-M1 & CAT-NB1)
(Attach not accepted by NW)
TS.39_2.3.2_REQ_001 2.1.1 (CAT-M1)
(Device Capability 2.1.2 (CAT-M1)
Procedure) 2.1.3 (CAT-M1)
2.1.4 (CAT-NB1)
2.1.5 (CAT-NB1)
2.1.6 (CAT-NB1)
2.1.7 (CAT-NB1)
2.1.9 (CAT-M1 & CAT-NB1)
4.1.5 (CAT-M1 & CAT-NB1)
TS.39_2.4.2_REQ_001 2.3.1.1 (CAT-M1 & CAT-NB1)
(Data Transfer) 2.3.1.2 (CAT-M1 & CAT-NB1)
2.3.1.3 (CAT-M1 & CAT-NB1)
2.3.1.4 (CAT-M1 & CAT-NB1)

V2.0 Page 64 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

MioT Requirement Test Case Comments

Requirements
Document
Section
4.3.1 (CAT-M1)
4.3.2 (CAT-NB1)
4.3.3 (CAT-M1 & CAT-NB1)
TS.39_2.4.2_REQ_002 EC-GSM-IoT Test Cases to be
(Data Transfer EC-GSM-IoT) defined when Manufacturer
support is available.
TS.39_2.4.2_REQ_003 About the performances tests,
(Data Throughput Values) it is recommended to run the
tests with the terminal to be
certified and with a reference
terminal such as, for instance,
a competitive terminal
available on the market. The
behaviour of the reference
platform will help to remove
any ambiguity about the test
results.
TS.39_2.5.1_REQ_001 2.4.1.1 (CAT-M1)
(Cell Reselection) 2.4.1.2 (CAT-NB1)
2.4.1.3 (CAT-NB1)
TS.39_2.5.1_REQ_002 2.4.2.1 (CAT-M1)
(CAT-M1 Handover)
TS.39_2.5.1_REQ_003 EC-GSM-IoT Test Cases to be
(Cell Reselection EC-GSM- defined when Manufacturer
IoT) support is available.

TS.39_2.6.2_REQ_001 2.3.2.1 (CAT-M1)

(Suspend) 2.3.2.2 (CAT-NB1)
TS.39_2.6.2_REQ_002 2.3.2.1 (CAT-M1)
(Resume) 2.3.2.2 (CAT-NB1)
TS.39_2.7.2_REQ_001 2.3.3.1 (CAT-NB1)
(CAT-NB1 Serving PLMN
Rate Control)
TS.39_2.7.2_REQ_002 2.3.3.2 (CAT-NB1)
(CAT-NB1 APN Rate
Control)
3 Enhanced TS.39_3.1.2_REQ_001 3.1.1 (CAT-M1 & CAT-NB1)
Coverage (Random Access) 3.1.2 (CAT-M1 & CAT-NB1)
TS.39_3.1.2_REQ_002 EC-GSM-IoT Test Cases to be
(Random Access) defined when Manufacturer
support is available.
TS.39_3.2.2_REQ_001 3.3.1 (CAT-M1 & CAT-NB1)
(CAT-M1 Data Transfer) 3.3.2 (CAT-M1 & CAT-NB1)
3.3.3 (CAT-M1 & CAT-NB1)
3.3.4 (CAT-M1 & CAT-NB1)

V2.0 Page 65 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

MioT Requirement Test Case Comments

Requirements
Document
Section
TS.39_3.2.2_REQ_002 EC-GSM-IoT Test Cases to be
(Data Transfer EC-GSM_IoT) defined when Manufacturer
support is available.
TS.39_3.2.2_REQ_003 3.3.1 (CAT-M1 & CAT-NB1)
(Data Transfer CAT-NB1) 3.3.2 (CAT-M1 & CAT-NB1)
3.3.3 (CAT-M1 & CAT-NB1)
3.3.4 (CAT-M1 & CAT-NB1)
4 Power TS.39_4.1_REQ_001 4.1.1 (CAT-M1 & CAT-NB1)
Test (PSM) 4.1.2 (CAT-M1 & CAT-NB1)
Cases 4.1.3 (CAT-M1 & CAT-NB1)
4.1.4 (CAT-M1 & CAT-NB1)
TS.39_4.1_REQ_002 4.2.1 (CAT-M1 & CAT-NB1)
(eDRX) 4.2.2 (CAT-M1 & CAT-NB1)
TS.39_4.1_REQ_003 4.1.6 (CAT-M1 & CAT-NB1)
(Reduced Power Drain in
PSM)
TS.39_4.1_REQ_004 EC-GSM-IoT Test Cases to be
(EC-GSM-IoT Reduced defined when Manufacturer
Monitoring) support is available.

TS.39_4.1_REQ_005 4.1.1 (CAT-M1 & CAT-NB1)

(Configuration of T3324 and
T3412 PSM)
TS.39_4.1_REQ_006 4.1.5 (CAT-M1 & CAT-NB1)
(Accept T3412 from NW)
TS.39_4.1_REQ_007 4.1.3 (CAT-M1 & CAT-NB1)
(Wake up during PSM)
TS.39_4.1_REQ_008 4.2.1 (CAT-M1 & CAT-NB1)
(Configurable eDRX cycle 4.2.2 (CAT-M1 & CAT-NB1)
times)
TS.39_4.1_REQ_009 4.2.1 (CAT-M1 & CAT-NB1)
(paging notoification during 4.2.2 (CAT-M1 & CAT-NB1)
eDRX cycle)
TS.39_4.1_REQ_010 4.2.2 (CAT-M1 & CAT-NB1)
(eDRX current drain)
TS.39_4.1_REQ_011 4.3.1 (CAT-M1)
(low transmit power 4.3.2 (CAT-NB1)
consumption) 4.3.3 (CAT-M1 & CAT-NB1)
5 Service TS.39_5.1.3_REQ_001 The oneM2M Service Layer
Layer interface test case SHALL
(Register with CSE on Sl
follow the test case defined in
platform)
the following oneM2M
Specifications:
[5] TS-0013 -

V2.0 Page 66 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

MioT Requirement Test Case Comments

Requirements
Document
Section
Interoperability_Testing:
RemoteCSE Management in
Clause 8.1.2
Application Entity Registration
in Clause 8.1.3
Container Management in
Clause 8.1.4
[6] TS-0017 - Implementation
Conformance Statements
TS.39_5.1.3_REQ_002 The oneM2M Service Layer
interface test case SHALL
(Management by SL
follow the test case defined in
platform)
the following oneM2M
Specifications:
[5] TS-0013 -
Interoperability_Testing:
RemoteCSE Management in
Clause 8.1.2
Application Entity Registration
in Clause 8.1.3
Container Management in
Clause 8.1.4
[6] TS-0017 - Implementation
Conformance Statements
TS.39_5.1.3_REQ_003 The oneM2M Service Layer
interface test case SHALL
(App on cloud side config)
follow the test case defined in
the following oneM2M
Specifications:
[5] TS-0013 -
Interoperability_Testing:
RemoteCSE Management in
Clause 8.1.2
Application Entity Registration
in Clause 8.1.3
Container Management in
Clause 8.1.4
[6] TS-0017 - Implementation
Conformance Statements
TS.39_5.2.3_REQ_001 The LwM2M standard provides
service enabler to the service
layer, as part of the
simplification needed for the
IoT actors. It shall follow the
test case defined in the
LwM2M Test Specifications:
OMA-ETS-LightweightM2M-
V1_0_1[4]

Application Data Container

Management in Clause 6.1.6
6 SIM/eUIC TS.39_6.1_REQ_001 UICC and USIM device
C OTA interface test cases SHALL

V2.0 Page 67 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

MioT Requirement Test Case Comments

Requirements
Document
Section
(UICC) follow the test cases defined in
documents [2] and [3]
referenced in Section 1.5.
TS.39_6.1_REQ_002 UICC and USIM device
(M2M-IUCC) interface test cases SHALL
follow the test cases defined in
documents [2] and [3]
referenced in Section 1.5.
TS.39_6.1_REQ_003 UICC and USIM device
(eUICC) interface test cases SHALL
follow the test cases defined in
documents [2] and [3]
referenced in Section 1.5.
TS.39_6.1_REQ_004 UICC and USIM device
(USIM/ISIM) interface test cases SHALL
follow the test cases defined in
documents [2] and [3]
referenced in Section 1.5.
7 USIM TS.39_7.3_REQ_001 USIM ToolKit device interface
Tool Kit (USIM Tool Kit) test cases SHALL follow the
test cases defined in document
[3], referenced in Section 1.5.
TS.39_7.3_REQ_002 USIM ToolKit device interface
(Pro-active Commands) test cases SHALL follow the
test cases defined in document
[3], referenced in Section 1.5
TS.39_7.3_REQ_003 USIM ToolKit device interface
(infomation) test cases SHALL follow the
test cases defined in document
[3], referenced in Section 1.5
8 Antenna It is expected that Antenna Test cases will be agreed with
Performa Performance in a free space Operators and Manufacturers
nce environment within relevant on a case by case basis.
bands and areas will be
complaint with 3GPP and
CTIA specifications
where/when they are
available.

9 Device TS.39_9.2_REQ_001 LWM2M test cases SHALL

Managem (Bootstrap) follow the test cases defined in
ent document [4], referenced in
(LwM2M) Section 1.5.
TS.39_9.2_REQ_002 LWM2M test cases SHALL
(ID and registration) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_003 LWM2M test cases SHALL
(config communication follow the test cases defined in

V2.0 Page 68 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

MioT Requirement Test Case Comments

Requirements
Document
Section
parameter – normal function) document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_004 LWM2M test cases SHALL
(config communication follow the test cases defined in
parameter – fallback) document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_005 LWM2M test cases SHALL
(firmware update) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_006 LWM2M test cases SHALL
(replace configured comm follow the test cases defined in
parameters) document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_007 LWM2M test cases SHALL
(security info update ota) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_008 LWM2M test cases SHALL
(report APP health follow the test cases defined in
information) document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_009 LWM2M test cases SHALL
(report location) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_010 LWM2M test cases SHALL
(data transfer to server) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_011 LWM2M test cases SHALL
(provide host information follow the test cases defined in
details) document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_012 LWM2M test cases SHALL
(basic diagnostic capabilities) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_013 LWM2M test cases SHALL
(basic observe/notify follow the test cases defined in
capabilities) document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_014 LWM2M test cases SHALL
(basic queue capabilities) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_015 LWM2M test cases SHALL
(report PSM information) follow the test cases defined in

V2.0 Page 69 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

MioT Requirement Test Case Comments

Requirements
Document
Section
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_016 LWM2M test cases SHALL
(update PSM) follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_017 LWM2M test cases SHALL
follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_018 LWM2M test cases SHALL
follow the test cases defined in
document [4], referenced in
Section 1.5.
TS.39_9.2_REQ_019 LWM2M test cases SHALL
follow the test cases defined in
document [4], referenced in
Section 1.5.

V2.0 Page 70 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Annex A Individual Test Scenario Classification and Proforma

This Annex contains the individual classification (i.e. whether a test applies to Field Test, Lab
Test or both) of every single test scenario. It can also be used as a blank proforma to record
the results of an individual test scenario.

Worksheet in TS-40
V2.0.xlsx

V2.0 Page 71 of 72
GSM Association Non-confidential
Official Document TS.40 - MIoT Field and Lab Test Cases

Annex B Document Management

B.1 Document History

Version Date Section Brief Description of Approval Editor /
No Change Authority Company
1.0 18 New PRD (CLP23 v0.1). TCJWG/PSMC
November David Hills
2016
2.0 December All New PRD (TS.40 v2.0) TSG / TG
2017 Initial official release of this Petra Rauer
document, approved by GSMA Vodafone
Plenary (TSG#30)

B.2 Other Information

Type Description
Document Owner Terminal Steering Group
Editor / Company Paul Gosden, GSMA

It is our intention to provide a quality product for your use. If you find any errors or omissions,
please contact us with your comments. You may notify us at [email protected]

Your comments or suggestions & questions are always welcome.

V2.0 Page 72 of 72