Kramer, Jörg, Vodafone Group

Device Requirements and Compliance Framework

Vodafone Group Products & Services Release 2019 – V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework C2 General

Current View
device-requirements-compliance-framework
Vodafone Group Products & Services
Device Requirements and Compliance Framework
Release 2019, Version 1.0.
This document is issued by Vodafone Group in confidence and is not to be reproduced in whole or in part without the prior written consent of Vodafone Group. This document remains the intellectual property of Vodafone Group.
This document gives an overview of the Vodafone Device Requirements and Compliance Framework. Suppliers that work with Vodafone need to fulfil a more comprehensive set of requirements, which goes beyond this extract. The full set of requirements will be made available once an NDA is in place. For more information please contact <xxxVPCxxx@vodafone.com>
Table of content: Part 1: Extract of Legislative and Industry Standards for Device Compliancy Part 2: Extract of Vodafone Quality & Safety criteria for Device Compliancy Part 3: Vodafone Device Requirements for Services & Applications

C2 General

Release 2019 ­ V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Services

Part 1: Extract of Legislative and Industry Standards for Device Compliancy

Extract Legislative and Industry Standards
Android

Content

Reference

The device shall pass the Android Compatibility Test Suite (CTS) & if it includes Google's services (like Maps, Play Store, Chrome & Search) shall pass the GMS Test Suite (GMS) and have a current (less than 90 days old at time of launch) "Android security patch level" (available in the Phone's Settings)

https://source.android.com/compatibil ity/cts https://www.android.com/intl/en_en/ gms/

Battery

Battery compliant with UN38.3, 2006/66/EC, IEC62133-2:2017, UL1642 (2012-03-13), IEC/EN 62368-1 (2017-07) and MSDS

Bluetooth
Charger and power supply efficiency
DoC

Bluetooth qualified by Bluetooth SIG
Charger and power supply efficiency level VI according to Commission Regulation and Department of Energy: (EC) No 278/2009 and Department of Energy, 10 CFR Parts 429 and 430 EN50563 (Phone chargers) or EN50564 (Power Supplies) Conformity Assessment was done according to RE-D Annex III module B and with EU27 based NB, EU Declaration of Conformity (DoC) signed, available and translated to local languages

Electrical Safety

Compliant with electrical safety EN60950 or with the new IEC62368

The eUICC and the device has to pass the

eSIM

GSMA's eSIM compliance process (GSMA

SGP.24)

 UN38.3 - shipment certificate 2006/66/EC - Europe battery regulation
 IEC 62133 - battery cell safety  UL1642 - battery cell safety
test requirements  EN/IEC 62368 - battery pack /
electrical safety  MSDS - Material Safety Data
Sheet (REACH)  IEEE 1725 - recommended to
verify e.g. battery production processes
https://www.bluetooth.com/specificati ons/bluetooth-core-specification/
https://ec.europa.eu/growth/singlemarket/europeanstandards/harmonisedstandards/ecodesign/powersupplies_e n
https://ec.europa.eu/info/sites/info/fi les/qa_brexit_industrial_products_en. pdf
https://webstore.ansi.org/standards/ie c/iec62368ed2014?gclid=EAIaIQobCh MIk8jp77HA4gIVzuF3Ch0f_QibEAMYAS AAEgJnNvD_BwE
www.gsma.com

C2 General

Release 2019 ­ V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Services

FCC GCF GDPR

Compliant with FCC requirements mandatory for devices which can operate in US bands
GCF certification passed
Compliant with EU General Data Protection Regulation (GDPR)

https://www.fcc.gov/general/equipme nt-authorization-procedures https://www.globalcertificationforum.o rg/
https://gdpr.eu/

Low Voltage Directive REACH RE-D RoHS SAR
TAC
Waste WEEE
WiFi

Compliant with Low Voltage Directive 2014/35/EU

https://ec.europa.eu/info/law/betterregulation/initiatives/ares-20175291384/public-consultation_en

Compliant with REACH incl. the latest restriction list

http://ec.europa.eu/environment/che micals/reach/reach_en.htm

Compliant with RE-D directive 2014/53/EU

https://ec.europa.eu/growth/sectors/ electrical-engineering/red-directive_en

Compliant with RoHS 2011/65/EU and its latest amendment lists
SAR hear and body certification passed

http://ec.europa.eu/environment/was te/rohs_eee/index_en.htm
https://www.bfs.de/EN/topics/emf/m obilecommunication/protection/precaution /sar-mobile-phone.html

TAC code for the product registered at GSMA,

IMEI security in accordance to 3GPP TS22.016 confirmed and IMEI range reserved/registered

www.gsma.com

for the product

Compliant with Packaging Waste Directive 94/62/EC

http://ec.europa.eu/environment/was te/packaging/legis.htm

Compliant with WEEE
Compliant with Wifi norms EN 300 328 and EN 301 893

http://ec.europa.eu/environment/was te/weee/index_en.htm
https://www.etsi.org/deliver/etsi_en/300300_ 300399/300328/02.01.01_60/en_300328v02 0101p.pdf ; https://www.etsi.org/deliver/etsi_en/301800_ 301899/301893/02.00.07_20/en_301893v02 0007a.pdf

C2 General

Release 2019 ­ V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
Part 2: Extract of Vodafone Quality & Safety criteria for Device Compliancy

Vodafone Quality & Safety creteria
Acoustic Safety

Content
Acoustic Shock and long term exposure tests done according to Vodafone specifications

Reference see Appendix 1

Antenna

Antenna test has been conducted by a Vodafone

approved Antenna laboratory anbd are

see Appendix 2

compliance with Vodafone Antenna specification

Release Notes Safety manual SAR Temperature Type Acceptance Vodafone Requirements
Vodafone Settings Vodafone Tests

Release Notes must be provided prior to

Details will be provided

acceptance start (for both new devices and MRs). during RFQ

Content of Safety manual is compliant with Vodafone EMF policy

Details will be provided during RFQ

SAR test has been conducted at Vodafone approved SAR laboratory Max temperature must stay with the limits as specified in Vodafone Spec for Terminals on Temperature of Touchable Surfaces

Details will be provided during RFQ
see Appendix 3

No blocking defect after Vodafone own Type Acceptance

All features and applications are implemented as specified in Request for Proposal and Vodafone Terminal Requirements

Details will be provided during RFQ

All required country variants and language versions are available and compliant to Vodafone variant settings database

Details will be provided during RFQ

agreed set of Vodafone test cases executed by Details will be provided

supplier and test results provided

during RFQ

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
Appendix 1: Extract of Acoustic Safety Requirements
1. Acoustic Shock
The test methodology for maximum acoustic output of terminal equipment as described in ETSI EG 202 518 allows the use of type 3.3 or type 3.4 artificial ears. Depending on the ear type strong variation of the measured maximum peak level can be detected especially for the abnormal use case applying the handsfree speaker (usually also used for ringtone playback) to the artificial ear with high application force".
- Requirement 1: Sound pressure level peaks for the sound outlet of the receiver of a terminal must never exceed 135 dBSPL (C) during first two seconds of time
- Requirement 2: Sound pressure level peaks for the sound outlet of the receiver must under no circumstances exceed 140 dBSPL (C)
2. Long Term Exposure
According to EN 60950-A12, no further safety actions are necessary for PMP's (Personal Music Player) which are distributed with headsets when it is ensured that the acoustical output LAeq (equivalent sound pressure level) is not higher than 85dB(A) when playback "program simulating noise" as described in EN 50332-1 and furthermore a maximum electrical output voltage of 27mV will not be exceeded on the electrical audio output connector.
All other devices must provide actions to protect the user against levels which are higher as mentioned above.
These actions are:
a.) Any kind of action which is able to protect the user against unintended SPL (Sound Pressure Level) which is higher than mentioned above.
b.) The PMP needs to have a default acoustical output level (standard level when powering on the PMP) which is not higher than mentioned above. Furthermore it must be ensured that the PMP returns automatically to this default level when it is switched off no matter which output level the user has been adjusted before switching off the PMP.
c.) The PMP must proactively inform the user in case the user is adjusting the settings so that an acoustical output level will be reached which is higher than the level mentioned above. The user needs in any case to confirm the activation of a higher acoustical output level before this setting will be activated. This confirmation must be provided by the terminal once within every 20 hours of cumulated listening. The cumulated listening time is independently from the time and frequency the PMP has been switched off.
d.) The max. acoustic output level of PMP´s while playback program simulating noise must not exceed a LAeq of 100 dB(A). Settings which may lead to higher acoustical output (e.g. setting of equalizer, bass boost function etc.) must be considered.
e.) If an audio connector (audio jack) is available a max. electrical output voltage of 150mV RMS must not be exceeded while play back program simulation noise. Settings which may lead to higher acoustical output (e.g. setting of equalizer, bass boost function etc.) must be considered.
f.) A warning symbol and a warning text according to EN 60950-A12 must be presented

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Appendix 2: Extract of Vodafone Antenna Requirements

Acceptance Limits for Narrow Phones (width: 56 - 72 mm)

Radio Technology Freq./MHz

2G /GSM 3G / UMTS
4G / LTE

900 1800 2100 900 800 1800 2600 700 2100 2600 TDD 1400 (DL) 900

Band
I VIII 20 3 7 28 1 38 32 8

TRP

TIS

Limit [dBm] tol.[dB] Final [dBm] Limit [dBm] tol.[dB] Final [dBm]

19

0

19

-95

0

-95

19

0

19

-97

0

-97

14

0

14

-100

0

-100

11

0

11

-96

0

-96

11

0

11

-86

0

-86

14

0

14

-90

0

-90

15

1

14

-91

1

-90

10

1

9

-85

2

-83

14

1

13

-90

2

-88

15

1

14

-91

2

-89

n.a.

n.a.

n.a.

11

1

10

-88

2

-86

-86

2

-84

tol. =Tolerance
Acceptance Limits for Wide Phones (width: >72 - 92 mm)

Radio Technology Freq./MHz

2G /GSM 3G / UMTS
4G / LTE

900 1800 2100 900 800 1800 2600 700 2100 2600 TDD 1400 (DL) 900

TRP

TIS

Band Limit [dBm] tol.[dB] Final [dBm] Limit [dBm] tol.[dB] Final [dBm]

19

1

18

-95

1

-94

19

1

18

-97

1

-96

I

14

1

13

-100

1

-99

VIII

11

1

10

-96

1

-95

20

11

1

10

-86

1

-85

3

14

1

13

-90

1

-89

7

15

1

14

-91

1

-90

28

10

2

8

-85

3

-82

1

14

2

12

-90

3

-87

38

15

2

13

-91

3

-88

32

n.a.

n.a.

n.a.

-88

3

-85

8

11

2

9

-86

3

-83

tol. =Tolerance

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
Appendix 3: Extract of Heating Safety Requirements
Heating Safety Limits
The classification for determining the Vodafone limits is the same as in EN 60950. Vodafone requires evaluating temperatures of touchable surface for an ambient temperature at 21°C, the limits stated below are 15 K lower than the limits (valid for any environment) defined by EN 60950.

Metal Ceramic and glass Plastic and rubber

External surface of equipment which may be touched
55°C 65°C 80°C

Knobs touched for a short period (10 s)
45°C 55°C 70°C

Handles or grips continuously held
in normal use
40°C 50°C 60°C

Vodafone temperature limits valid for an ambient temperature of 21°C for relevant conditions.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Part 3: Extract of Vodafone Device Requirements for Services & Applications

Section SIM SIM
SIM SIM SIM
SIM SIM SIM SIM

Technology/ proposition Dual SIM
Consumer eSIM
Consumer eSIM
Consumer eSIM
Consumer eSIM
Consumer eSIM
Consumer eSIM
Consumer eSIM
Consumer eSIM

SubSe Requirement

ction

Name

Requirement Description

Impact Analysis/Supplementary Information

IMS Services Continuation
Confirmation Code Request
Profile Download Procedures Activation Code Entry

Based on device Capabilities: the IMS services (VoLTE, VoWiFi), shall continue to work regardless of SIM card change or SIM swap. The device shall support an unlimited number of IMS reconfiguration for both SIM slots. When downloading an eSIM profile, the device shall prompt the user to enter a confirmation code only if ,,Confirmation Code Required Flag" (ccRequiredFlag) is set to True in smdpSigned2. The device shall NOT prompt the user to enter the Confirmation Code in case that Confirmation Code Required Flag is ONLY set in Activation Code AND NOT in smdpSigned2. The device shall support Profile download via SM-DS service discovery (based on the GSMA Root SM-DS address stored on the eUICC) and via the Activation Code procedure. The device (LPAd) shall support entry of the Activation Code by manual typing (including copy/paste function) and QR code scanning.

If re-configuration is not supported, customers losing IMS services at SIM change or SIM swap (operator switch).
Confirmation Code Request shall depend on SM-DP+ profile setting (smdpSigned2) only
Required for Devices supporting GSMA Consumer RSP
Required for Devices supporting GSMA Consumer RSP

Support of network attach repetitions
eUICC GSMA RSP specification compliance
eUICC minimal category

After successfully enabling a profile (see GSMA SGP.22, section 3.2.1) the device shall repeat the network attach procedure for 2 minutes in case the network rejects the attach attempt with reject cause "IMSI unknown in HLR". If the device embeds an eUICC, the eUICC shall be fully compliant to GSMA RSP Architecture (SGP.21 v2.2 or higher) and GSMA RSP Technical Specification (SGP.22 v2.2 or higher) If the device embeds an eUICC, the minimal category of the eUICC shall be 'Medium eUICC' (CAT2) as defined in GSMA SGP.22

Required for Devices supporting GSMA Consumer RSP
Required for Devices supporting GSMA Consumer RSP
Required for Devices supporting GSMA Consumer RSP

GSMA RSP specification compliance
Display of Error Indications

The device (LPA) shall be fully compliant to GSMA RSP Architecture (SGP.21 v2.2 or higher) and GSMA RSP Technical Specification (SGP.22 v2.2 or higher) The device/LPA shall provide an appropriate error indication to the user in case of detected failures during the profile download and installation procedures.

Required for Devices supporting GSMA Consumer RSP
Required for Devices supporting GSMA Consumer RSP

Refs. N/A
GSMA SGP.22
GSMA SGP.22
GSMA SGP.22
GSMA SGP.22
GSMA SGP.21 GSMA SGP.22 GSMA SGP.22
GSMA SGP.21 GSMA SGP.22

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Consumer

eSIM

SIM

Consumer

eSIM

SIM

General

SIM

General

SIM

General

eUICC GSMA RSP compliance process

If the device embeds an eUICC, the eUICC has to pass the GSMA's RSP compliance process (SGP.24) and shall have a PKI certificate from a GSMA certificate issuer. See "http://www.gsma.com/rsp/guide-rspcompliance-process/".

Required for Devices supporting GSMA Consumer RSP

GSMA SGP.24

GSMA RSP compliance process

The related self-declaration form shall be provided to Vodafone The device (LPA) has to pass the GSMA's RSP compliance process (SGP.24). See "http://www.gsma.com/rsp/guide-rspcompliance-process/"

Required for Devices supporting GSMA Consumer RSP

GSMA SGP.24

ADN and EXT1
Number of PLMN entries to be read from a USIM
Display of Service Provider name

The related self-declaration form shall be provided to Vodafone The MS shall support the reading of a 40 digit dialling number in the USIM using EF_ADN and EF_EXT1.

The ADN (Abbreviated Dialling Number) is a series of files in a SIM which contains phonebook information for users.

The terminal shall read and utilise, for the purpose of network selection, at least the first 127 entries from OPLMNwACT where a USIM is used with the terminal. The terminal shall support displaying of the Service Provide Name (based on content of EF_SPN).

To ensure a list of at least 127 operators can be listed in the SIM for preferred network lists - for roaming.
To ensure that the handset is able to display Service Provider Name as defined by the operator by EF_SPN

SIM

General

SIM

Security Codes

Standards support for UICC-Terminal Interface
PIN/PUK Remaining Number of Attempts Notification

Terminal shall be fully compliant to Release 8 (or hiigher) of the ETSI TS 102 221 "UICC-Terminal interface" specification
During PIN/PIN2 and PUK/PUK2 entry, the terminal shall display the remaining number of entry attempts.

This requirement mandates the compliancy to the UICC-Terminal interface specification
Description: This requirement describes how UI handling must be done for SIM/USIM activation PINs

Priority: Mandatory

ETSI TS 102 221

SIM

Security Codes

PUK prompt

If the user fails to correctly enter their PIN 3 consecutive times, causing the (U)SIM to be locked the terminal shall prompt the user to enter the PUK code. Additionally the terminal shall prompt the user to contact their customer care to obtain their PUK code. The last prompt should be customisable per OpCo.

Non-Compliance Impact: Noncompliances might result in user blocking the SIM/USIM and calling the customer care for help. Description: This requirement describes how UI handling must be done for SIM/USIM activation PINs
Priority: Mandatory
Non-Compliance Impact: Noncompliances might result in user blocking the SIM/USIM and calling the customer care for help. This can increase the load on VF Customer care calls.

Impact for Embedded SIM:

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Security Codes

SIM

Security Codes

Why Required: To meet some Vodafone Operator security requirements

PUK2 Prompt

If the user fails to correctly enter their PIN2 code 3 consecutive times, the terminal shall prompt the user that PIN2 is locked and that some functions will be unavailable. The terminal shall prompt the user to enter the PUK2 code. Additionally the terminal shall prompt the user to contact their customer care to obtain their PUK2 code. The last prompt should be customisable per OpCo.

What happens if not implemented? Acceptance criteria for launch will not be met in some Vodafone markets Description: This requirement describes how UI handling must be done for SIM/USIM activation codes PIN2.
Priority: Mandatory
Non-Compliance Impact: Noncompliances might result in user blocking the SIM/USIM and calling the customer care for help. This can increase the load on VF Customer care calls.

Impact for Embedded SIM: Why Required: To meet some Vodafone Operator security requirements

PUK Entry Failure Prompt

If the user fails to correctly enter their PIN Unblocking Code (PUK code) 10 consecutive times, causing the (U)SIM to be locked, the terminal shall prompt the user that the (U)SIM card is locked completely and to contact their customer center.

What happens if not implemented? Acceptance criteria for launch will not be met in some Vodafone markets Description: This requirement describes how UI handling must be done for SIM/USIM unblocking PINs (PUK).
Priority: Mandatory

SIM

Security Codes

Non-Compliance Impact: Noncompliances might result in users completely blocking their the SIM/USIM and requiring a replacement SIM/USIM.

Impact for Embedded SIM: Why Required: To meet some Vodafone Operator security requirements

PUK2 Entry Failure Prompt

If the user fails to correctly enter their PUK2 code 10 consecutive times, causing the (U)SIM to be locked the terminal shall prompt the user that the (U)SIM card is locked completely and to contact their customer center.

What happens if not implemented? Acceptance criteria for launch will not be met in some Vodafone markets Description: This requirement describes how UI handling must be done for SIM/USIM unblocking PINs (PUK2).

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Priority: Mandatory

SIM

SIM

Application

Toolkit

SIM

SIM

Application

Toolkit

SIM

SIM

Application

Toolkit

SIM

SIM

Application

Toolkit

Non-Compliance Impact: Noncompliances might result in users completely blocking their the SIM/USIM and requiring a replacement SIM/USIM.

Impact for Embedded SIM: Why Required: To meet some Vodafone Operator security requirements

Letter class "e" (BIP) support
Refresh mode support
SIM OTA capability Standards support for SIM Application Toolkit

The terminal shall support SIM Application Toolkit as per letter class "e" (support of BIP channels) defined in ETSI TS 102 223 for: - TCP and UDP in UICC client mode shall be supported - TCP in terminal server mode should be supported All refresh modes as defined in ETSI 102 223 and 3GPP TS 31.111 shall be supported. The list of current refresh modes is: · NAA Initialization · File Change Notification · NAA Initialization and File Change Notification · NAA Initialization and Full File Change Notification · UICC Reset · NAA Application Reset · NAA Session Reset · Steering of Roaming
Upon reception of REFRESH command during ongoing data connection (PDP context) the execution of the command has precedence. The terminal shall execute the REFRESH rather than answer with busy statement.
The Terminal shall support the SMS-PP DOWNLOAD and SEND SHORT MESSAGE proactive commands. These commands are required to support the update of file content on the SIM profile via OTA-RFM operation Terminal shall be fully compliant to Release 10 (or higher) of the following ETSI and 3GPP specifications:
- 3GPP TS 31.111 "Universal Subscriber Identity Module (USIM) Application Toolkit (USAT)" - ETSI TS 102 223 "Smart Cards; Card Application Toolkit". - 3GPP TS 31.124 "Universal Subscriber

What happens if not implemented? Acceptance criteria for launch will not be met in some Vodafone markets This requirement defines the class of the STK implementation required.

ETSI TS 102 223

The purpose of this command is to enable the handset to be notified of the changes to the SIM configuration that have occurred as the result of a SIM application activity.

3GPP TS 31.111 ETSI TS 102 223

Impact for Embedded SIM: For Embedded SIM terminals the NAA Initialization and Full File Change Notification mode must be supported. Why Required: To notify the Terminal that the SIM Profile has changed after SIM transformation. The specific mode that is used notifies the Terminal to reread the SIM profile without requiring a device reboot.

What happens if not implemented? Not having this feature will affect the user experience as the Terminal will need to be manually powered down and power up again after the SIM transformation. Required to support the update of file content on the SIM profile via OTA-RFM operation

This requirement mandates the standards compliance for terminals.

3GPP TS 31.111 ETSI TS 102 223 3GPP TS 31.124

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Identity Module Application Toolkit (USAT) conformance test specification", Annex B

SIM

SIM

Application

Toolkit

BIP over IPv6

If BIP is supported, the end to end

IPv6 support needed for all internet

connection shall also operate via IPv6. connections

SIM

SIM

Application

Toolkit

SIM

Consumer

eSIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Consumer

eSIM

SIM

Consumer

eSIM

Refresh mode "NAA Initialization and Full File Change Notification" support in managed roaming case
Profile Deletion Visual Confirmation
IMS (VoLTE, VoWiFi) support for all SIM's identity IMS call service transparency to the user Master software
eUICC Test Profile support

In the case of a REFRESH with command qualifier "NAA Initialization and Full File Change Notification" the network attachment parameters may have changed, so it is essential to setup new connections (voice and data) according to the following requirements: - terminate all data connections (internet, BIP, etc.) and DO NOT answer with "Terminal busy" or similar Terminal Response to active Toolkit applications - Disconnect from the current network immediately and connect to the target network (using freshly read PLMN files, EFLoci, EFPSLoci) - Shall not send a TERMINAL PROFILE while executing the REFRESH procedure; - Shall not update any files on the UICC between reception of the REFRESH command and executing the REFRESH procedure (e.g. to avoid updating of network related EFs) - Send a TERMINAL RESPONSE to indicate a successful REFRESH procedure Upon eSIM Profile deletion, the device shall advise the end user to keep an internet connectivity during and after the deletion to ensure the sending of the Delete Notification to the SM-DP+. Once Delete Notification is sent, the device shall give a visual confirmation to the end user. This can be achieved through a message, through a visual aid (delete icon turning green) or another appropriate mean. The device shall support IMS (VoLTE, VoWiFi) registration simultaneously with all SIM identities enabled in the device.
The device shall handle IMS calls (VoLTE, VoWiFi) in same way (transparent) as cellular speech calls for both SIM identities to the user.
A PC software should be available to enable the customer care to initiate a 'eUICC Memory Reset' (according to GSMA SGP.22) via USB cable connection. If the device embeds an eUICC, the eUICC shall support 'Test Profiles' as defined in GSMA SGP.22

This requirement is needed to ensure the correct support of a current SIM based VF solution for Steering of Roaming. Why Required: To notify the Terminal that the SIM Profile (including network attachment parameters) has changed and a new network attachment (using freshly read PLMN files,EFLoci, EFPSLoci) has to be done. The specific REFRESH mode that is used does not require a new PIN verification. What happens if not implemented? Non-support of this feature will restrain VF of carrying out successful SIM based Steering of Roaming.
Required for Devices supporting GSMA Consumer RSP
Necessary for reliable service continuation available for the user.
Necessary to ensure a seamless call service experience in Multi-SIM environment.
Required for Devices supporting GSMA Consumer RSP
Required for Devices supporting GSMA Consumer RSP

N/A
N/A
GSMA SGP.22
GSMA SGP.22

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Consumer

eSIM

Device Test Mode support

The device and LPAd shall support 'Device Test Mode' as defined in GSMA SGP.22

Required for Devices supporting GSMA Consumer RSP

GSMA SGP.22

SIM

Consumer

eSIM

SIM

Customization

SIM

Device Access

Control

SIM

Device Access

Control

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

Download Progress Indication
Operation without SIM / Emergency call
UICC Carrier Privileges Rules in ARF
UICC Carrier Privileges

A progress indication for the profile download status shall be shown to the user on Primary or Companion Device (depending on UI availability)

Required for Devices supporting GSMA Consumer RSP

The device shall support appropriate operation without SIM (i.e. all functions that do not require cellular), in particular the implementation shall comply with the respective OpCo and legal requirements for emergency calls. In case no ARA-D/ARA-M exist on the UICC, the Access Control Enforcer (ACE) shall retrieve access rules with the AID (or tag AID-REF-DO) set to "FF FF FF FF FF FF" as a UICC Carrier Privilege rule. The Terminal shall support GlobalPlatform 'Device API Access Control' (DAC) version 1.0 (or higher). In case an ARA-D/ARA-M application exists on the UICC, it shall be used to retrieve access rules.

Required to support UICC Carrier Privileges with existing VF SIM cards
Required to support UICC Carrier Privileges

Network Operator name
Roaming indicator
Emergency call

Network operator name short code shall be shown in the UI where applicable to differentiate both SIM cards.
A Dual SIM capable terminal shall indicate a separate roaming indicator for each of the two network connections along with the network received signal strength
A Dual SIM capable terminal shall attempt to make emergency calls using the network connected by the SIM chosen as Primary SIM, and if this is not successful should then attempt to

This Dual SIM requirement is valid as long as a GSMA and GCF specifications are not in place and approved, as currently stated oin GSMA daft spec TS 37, (tested in TS 42). Once a GSMA standard is covering this requirements, this requirememts will be replaced by a support reference to relevant standard requirement. Supported in terminals which are ranged as Dual SIM devices for specific requested countries, implementation details as specified in the device TPD, specific Dual SIM settings per country as noted in VVS apply. This Dual SIM requirement is valid as long as a GSMA and GCF specifications are not in place and approved, as currently stated oin GSMA daft spec TS 37, (tested in TS 42). Once a GSMA standard is covering this requirements, this requirememts will be replaced by a support reference to relevant standard requirement. Supported in terminals which are ranged as Dual SIM devices for specific requested countries, implementation details as specified in the device TPD, specific Dual SIM settings per country as noted in VVS apply. This Dual SIM requirement is valid as long as a GSMA and GCF specifications are not in place and approved, as currently stated oin GSMA daft spec TS 37, (tested in TS

GlobalPl atform 'Device API Access Control' (DAC) N/A
N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

use the network connected by the

42). Once a GSMA standard is

Secondary SIM, If this also fails then

covering this requirements, this

standard emergency call access

requirememts will be replaced by a

procedures should be used.

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Network

A Dual SIM capable terminal shall have This Dual SIM requirement is valid as N/A

settings are separate network settings per SIM. For long as a GSMA and GCF

supported on example: Typical network settings such specifications are not in place and

per SIM basis as COLP, CLIP/CLIR, APN are applicable approved, as currently stated oin

to SIM slot 1 and 2.

GSMA daft spec TS 37, (tested in TS

42). Once a GSMA standard is

covering this requirements, this

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Single SIM

Dual SIMs shall be compliant to

This Dual SIM requirement is valid as N/A

requirements requirements defined in SIM section: long as a GSMA and GCF

are applicable. SIMs i.e. UICC / eUICC used in Dual SIM specifications are not in place and

Devices shall work in same way as

approved, as currently stated oin

designed in Single SIM devices. I.e. they GSMA daft spec TS 37, (tested in TS

shall support relevant capabilities as 42). Once a GSMA standard is

defined in SIM requirement section of covering this requirements, this

this TCD document

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Dual SIM

The device need to indicate Network This Dual SIM requirement is valid as N/A

Network signal signal strength on a per SIM card basis. long as a GSMA and GCF

strength

specifications are not in place and

indication

approved, as currently stated oin

GSMA daft spec TS 37, (tested in TS

42). Once a GSMA standard is

covering this requirements, this

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

IMEI-SV

As an IMEI must be assigned per SIM This Dual SIM requirement is valid as N/A

slot, the following definition shall

long as a GSMA and GCF

apply: The SV digits of a multi - IMEI-SV specifications are not in place and

device must be identical to reflect the approved, as currently stated oin

same SW version for one product with GSMA daft spec TS 37, (tested in TS

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

assigned different IMEIs. In case a

42). Once a GSMA standard is

primary IMEI is defined, the IMEI-SV

covering this requirements, this

shall be assigned to this primary IMEI. requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Operator and The Dual SIM device needs to indicate This Dual SIM requirement is valid as N/A

Radio Access the Mobile Operator / related service long as a GSMA and GCF

Technology operator network name and Radio

specifications are not in place and

(RAT)

Access Technology (e.g. E, H+, etc) on approved, as currently stated oin

Indication

per SIM basis.

GSMA daft spec TS 37, (tested in TS

42). Once a GSMA standard is

covering this requirements, this

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

SIM Call Log The device has to ensure that call

This Dual SIM requirement is valid as N/A

logging is performed on per SIM basis long as a GSMA and GCF

in order to let the end user identify

specifications are not in place and

calls history per SIM

approved, as currently stated oin

GSMA daft spec TS 37, (tested in TS

42). Once a GSMA standard is

covering this requirements, this

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

SIM SMS Log The device has to ensure that the SMS This Dual SIM requirement is valid as N/A

history are correctly logged on per SIM long as a GSMA and GCF

basis. For example, this means that

specifications are not in place and

SMS received on SIM 2 card are kept approved, as currently stated oin

and linked to SIM 2 phone number

GSMA daft spec TS 37, (tested in TS

which separate & different from SMS 42). Once a GSMA standard is

history for SIM 1 card.

covering this requirements, this

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Data download If the data download is interupted (e.g. This Dual SIM requirement is valid as N/A

incoming call), then it shall resume

long as a GSMA and GCF

when applicable (e.g. after hang up of specifications are not in place and

incoming call) on the relevant SIM card approved, as currently stated oin

(e.g. started on SIM 1 card, the resumed GSMA daft spec TS 37, (tested in TS

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

on SIM 1 card).

42). Once a GSMA standard is

covering this requirements, this

requirememts will be replaced by a

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Emergency

Whenever an emergency call is

This Dual SIM requirement is valid as N/A

call without initiated there shall be no additional long as a GSMA and GCF

interrupts/pro dialog to indicate which SIM card

specifications are not in place and

mpts

should be used. The emergency call approved, as currently stated oin

shall be initiated immediately without GSMA daft spec TS 37, (tested in TS

prompting any further SIM selection 42). Once a GSMA standard is

pop-ups to the user which might

covering this requirements, this

delay/hold/disconnect an emergency requirememts will be replaced by a

call setup.

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Primary IMEI In a Dual SIM capable terminal (2

This Dual SIM requirement is valid as N/A

on Dual SIM separate physical SIM card readers or 1 long as a GSMA and GCF

devices

SIM card reader = Hybrid SD/SIM), the specifications are not in place and

device shall have a primary IMEI

approved, as currently stated oin

assigned. Even if the Dual SIM terminal GSMA daft spec TS 37, (tested in TS

utilitzes simultaneously active SIM

42). Once a GSMA standard is

implementation (e.g. DSDA), there shall covering this requirements, this

be only one IMEI designated as

requirememts will be replaced by a

primary.

support reference to relevant

standard requirement.

Supported in terminals which are

ranged as Dual SIM devices for

specific requested countries,

implementation details as specified

in the device TPD, specific Dual SIM

settings per country as noted in VVS

apply.

Vodafone

Upon Vodafone SIM detection, the

All Vodafone services shall be

N/A

Network

relevant network settings (eg. APN) as supported on Vodafone SIMs and

Settings

outlined in Vodafone Variant Settings shall work regardless of physical

(VVS) database are applied in multi-SIM and/or eSIM combinations.

environment.

Vodafone

Upon Vodafone SIM detection, the

All Vodafone services shall be

N/A

Network

relevant network service configuration supported on Vodafone SIMs and

Service

settings (eg. VoLTE, VoWiFi, etc.) as

shall work regardless of physical

Configuration outlined in Vodafone Variant Settings and/or eSIM combinations.

(VVS) database are applied in multi-SIM

environment.

UX SIM

The UX SIM management and relevant All Vodafone services shall be

N/A

management user expereience shall be the same for supported on Vodafone SIMs and

handling

a physical SIM and/or an eSIM

shall work regardless of physical

combination

and/or eSIM combinations.

Service setup at Vodafone SIM detection

Upon Vodafone SIM insertion and/or Upon Vodafonr SIM insertion on a

N/A

active eSIM profile, the relevant

DSIM devcie, all Vodafone services

Vodafone Service settings and

shall be supported on Vodafone SIMs

customization shall apply during setup and shall work regardless of physical

(OOBE) on applicable SIM slot/eProfile. and/or eSIM combinations.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM

Dual SIM

SIM Service

On Dual-SIM phone, the service

N/A

Settings

options should be visible to the user

(e.g. icon/text/etc)

Current selction choice on

,,preferred/always ask" for voice, data,

IMS and SMS per SIM visibility to users

OOBE

In DSIM OOBE or any SIM card change

N/A

Vodafone

(e.g. swap, additonal SIM card, new

Network

eSIM profile, 2x VF SIMs, etc.) with

settings

detected VF SIM following SIM

Managment parameters shall be

preset: SIM slot name= Vodafone,

MSIDN to be displayed and

Voice/SMS/Data = Vodafone.

However, the end user is allowed to

edit these settings. In case of 2 VF SIMs

inserted, then the all Services

(Voice/Data/SMS) shall be applied to

the slot with highest Radio Access

Technology (RAT). For example, SIM

Slot 1= VF SIM with 4G and SIM slot 2=

VF SIM with 3G, the SIM slot 1 will be

the default for all services.

SIM Mgmt

During OOBE and/or any SIM change

N/A

Default

with detected VF SIM , VF Services shall

settings

be set as default in SIM Mgmt settings

for Voice/SMS/Data. The default

settings can be changed by the end

user.

Device

A Dual SIM device shall support the

This varies based on the device tier. N/A

Capability

latest radio technology (e.g. 4G, 5G,

For example:Flagship devices = Slot 1

IMS services, etc.) on the each active & 2 = 4G, Mid tier device = Slot 1 (4G)

SIM/eSIM. This requirement is

& Slot 2 (3G/2G)

dependant on the product definition

and/or proposition.

Call Handling When each MSISDN (e.g. SIM card,

N/A

in Multi SIM eSIM) recieves an incoming call at the

enviroment - same time or sequential, then the

Incoming calls expected behaviour shall be based on

the Dual SIM (DS) implmentation:

1) DSSA (Single Active): This will

behave as Single SIM device.

2) DSDS (Dual Standby) : Only one call

can be recieved and other call

behaviour (e.g. not available, busy, call

diversion, etc.) shall adhere to relevant

standards.

3) DSDA (Dual Active): Should recive

and handle (e.g. hold, connect, swap,

merge, call knocking, etc.) both calls as

defined in relevant standards.

VF IMS

The IMS Service experience should be

N/A

Services

similar as an inbound/outbound CS

(VoLTE,

call. For example, the device is

VoWiFi, ViLTE, registered in 2 IMS stacks

etc.)

If the device is registerd in a VF IMS

service (e.g. VoLTE, ViLTE, VoWiFi), then

it shall be possible to use those service

irrespective of the data connection on

a different network. For example, VF

SIM with VoLTE is registered on SIM

slot 1 and then the data barrier is

changed to SIM slot 2, a VoLTE call

WiFi data connection available as selection on DSIM (with or without

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

cellular connection): All IMS service

relevant settings / APN's should be

available as OOBE at Vodafone SIM

detection when SIM is authorized for

this service (EAP-SIM for VoWiFi etc.)

with enabled IMS services for Vodafone

networks (VoLTE, VoWiFi and ViLTE).

SIM

Dual SIM

IMS Service

As soon as Cellular data connection

N/A

Authorization available (not WiFi), all IMS relevant

service settings (e.g. APN's) should be

available during OOBE upon Vodafone

SIM detection. When SIM is authorized

for a service (e.g. EAP-SIM for VoWiFi,

etc.), the enabled IMS services shall

apply to the relevant Vodafone

networks (VoLTE, VoWiFi and ViLTE).

SIM

Dual SIM

IMS Service

Upon detection of IMS enabled

N/A

Continuation Vodafone SIM, the Vodafone IMS setup

shall be done during OOBE and VF IMS

service shall be set as default with

possibility to be changed later by end

user.

SIM

Dual SIM

IMS Services Upon Vodafone SIM insertion, the

N/A

for Vodafone available IMS services shall be setup as

Network

prefered but later on the end user

change/adjust it accordingly.

SIM

Dual SIM

UX SIM

The end user should have full control

N/A

Management - which MSISDN (e.g. SIM card) to be

Inboud/Outbo used in a call scenario. For example,

und call

SIM card 1 is set as default for outgoing

calls. When an incoming call is recieved

on SIM card 2 and the end user

performs a call back via the call history

log, then end user be presented a

choice which MSISDN (e.g. SIM card) to

call back the B-party on. This is

applicable in Buisness vs. Private Dual

SIM use case.

User should have full control of

assigned or selected MSISDN of

outgoing (MO) and incoming (MT) calls.

SIM

Dual SIM

SIM swap or Upon SIM swap or SIM change, the

N/A

change -

relevant history (e.g. call log, data

History/Prefer preferences) shall follow the MSISDN

ences

(e.g. SIM card).

For example, SIM Slot 1 = Buisness SIM

card (which is selected for data) and

SIM slot 2 = Private SIM; then upon SIM

swap (Slot 1= Private SIM card & Slot

2= Buisness SIM card) this means that

when end user can still see the

call/SMS history of Buisness SIM and

that it is remained as the prefered SIM

card for data connection.

SIM

Dual SIM

Application

The data connection prefences shall be

N/A

level

defined in SIM Mgmt menu and

addionally it shall be possible to define

the data per applications. For example,

Browsing on SIM 1 and Instagram on

SIM 2.

SIM

Dual SIM

SIM Swap

A SIM swap scenario shall not impact

N/A

private data or settings (e.g. change

widget, delete pictures, etc.) except the

SIM Management settings (e.g. SIM

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mgmt pop up window).

During a SIM swap scenario and VF SIM

is inserted in SIM slot 1 or 2, the

exisiting IMS service shall continue

working.

SIM

Dual SIM

Single SIM

If there is only 1 SIM is inserted or 1

N/A

Insertion in

actived eSIM profile, then SIM

Multi-SIM

managment shall behave as Single SIM

enviroment device. This means that all applicable

services are enabled on the only active

SIM.

SIM

GBA

SIM

GBA

SIM

General

SIM

General

SIM

General

SIM

General

Support for GBA for establishing TLS connections SIM mechanisms for managing secret keys on devices

The device browser shall support GBA for establishing TLS connections according to 3GPP TS 33.222.
The IoT device shall support USIM including the commands defined in ISO/IEC 7816-4. The access can be provided by use of the AT+CSIM commands of class 00 over a serial modem interface, or by a library function if such exists. The support of the AUTHENTICATE command is essential. Supporting the access to UICC required also: - An HTTP networking interface to enable the device to communicate with the servers over the internet. - Sufficient space to be installed both for code and memory.

This is to show intent for future requirements, and compliance is encouraged rather than mandated at this stage.
Required to ensure secure handling of secret keys on IoT devices.

3GPP TS 33.222
ISO/IEC 7816-4

PPS Support
ICCID retrieval SIM Lock

Where modems are provided documentation and configuration information shall be supplied to define how the GBA AT+CSIM commands should be submitted from the modem to the SIM. The terminal shall support the PPS procedure (selective and negotiable mode) according to ETSI 102 221 section 6.3.2. The minimal supported Fi/Di factor, which is given inside the ATR of the SIM card, shall be '96' (Fi = 512 / Di = 32). If this requirement is not supported the communication between the UICC and the terminal will be too slow and the user experience will degrade. The device shall expose a API that allows a device application to retrieve the ICCID of the UICC that is placed inside the device.

PPS is the baud rate of data transfer of files between the SIM and the terminal

OpCos requesting SIM lock shall be supported using a MCC MNC locking mechanism.

ETSI TS 102 221

Operation with The terminal shall support operation

SIMs

with at least 1.8V technology UICCs.

to ensure that VF SIM cards are supported

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

SIM

General

SIM

General

SIM

General

Copying of USIM phonebook and internal terminal phonebook entries
Display of Operator defined network name
SDN support

The MS shall support an automatic function to import all entries of the USIM phonebook to the phonebook in the handset when a new USIM is inserted. The MS shall also support separate menu functions to: i) Import all the USIM phonebook to the phone book in the handset. ii) Export phone book entries in the handset to the USIM phonebook. The terminal shall reading of the Operator PLMN List (EF_OPL) and the PLMN Network Name (EF_PNN) files.
The handset shall be able read EF_SDN and shall be able to display SDN entries.

SIM Addressbook related. This provides the user with an easy means to transfer numbers from the SIM to the terminal and vice versa.
To indicate for which Location Area Identities a required network name is to be displayed
SDN = Service Dialling Number.

SIM

SIM

Application

Toolkit

SIM

UICC Access

Control

Device Manage ment

OMA CP

SIM Card busy

In case that a LOCATION_STATUS_EVENT is sent to the card and the card responds with 93 00 (SIM application busy) the handset shall resend the LOCATION_STATUS_EVENT to the card.

Feature is in use by OpCos like VF DE for their local applications and is required to retry event if the SIM card is busy.

OMAPI support
OTA Provisioning of service access settings

If the location information and/or the location status changes during the retry period the MS shall use the latest information for the LOCATION_STATUS_EVENT. In order to enable mobile applications accessing the UICC, the terminal shall support GlobalPlatform 'Open Mobile API Specification' (OMAPI) version 3.2 (or higher).
The terminal shall provide the ability to configure network, access and routing information via OTA mechanisms acceptable to Vodafone but with suitable protection to avoid fraudulent or inappropriate changes.
At least it must be possible to configure over the air all the following network configuration settings (where features are available on the terminal): 1) GPRS NAP 2) WAP access 3) MMS access 4) Email settings

To enable access to Vodafone services (e. g. VF MobileMail, MMS, WAP Portal) and increase the takerate, devices have to be provisioned via OMA CP. If client provisioning via OMA CP fails, the following opportunities are not working: - Provisioning of non-Vodafone branded devices - Correction of misconfigured clients - Reconfiguration of devices in case of changes of network elements and their access parameters
Impact for Embedded SIM (preferred): Why Required: For device configuration and settings.

GlobalPl atform 'Open Mobile API Specifica tion' (OMAPI) N/A

What happens if not implemented? For the network to be able to send settings to the device.

If not present, the user must manually configure the device OR the OEM must pre-installed device settings.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Device Manage ment

FOTA

Device Manage ment

FOTA

Device Manage ment

OMA CP

Device Manage ment

OMA CP

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Firmware Update over the air (FOTA) normal and emergeny updates Firmware Update over the air (FOTA) general requirements
OTA Update on multiple Applications
PIN Code Input Screen
OMA LwM2M 1.0 support
OMA LwM2M 1.1 support
De-registration

FOTA needs to be supported in two variants: FOTA updates with required user consent via the user interface for normal (scheduled) FOTA updates, as well as FOTA updates without user consent for emergency FOTA Updates e.g. critical patches. The FOTA client shall support:
- regular polling for new firmware version - power state / battery level check before FOTA update - full recovery in case of loss of power or coverage - seamless user experience and protection of all user data A single provisioning document may include all settings of multiple applications (e.g. Browser, MMS, APN settings, ...), subject to Operator transport size limitations. The maximal number of supported concatenated SMS for each OpCO is described in Vodafone Variant Sheet (VVS). The device shall support USERPIN & NETWORKPIN security mechanisms. If USERPIN mechanism is used, the device shall also display PIN code input screen for authorization. If NETWPIN mechanism is used, there shall be no user notification and the message shall be stored automatically in the background. Compliance to LwM2M 1.0 is requested which includes support of all mandatory protocol features plus all mandatory Objects and Resources. The LWM2M Client shall reside on the device e.g. integrated as SW library or build-in function.
Compliance to LwM2M 1.1 is preferred, however, standard was only released in 2018. LwM2M 1.1 provides improved support for NB-IoT, and other significant enhancements. Support of "De-register" operation enables the LwM2M Client to deregister from the LwM2M Server.

To ensure that multiple applications can be provisioned by using one client provisioning message and the installation of "Combined Settings" is implemented correctly. To ensure settings sent in more than one SMS are implemented correctly Essenstial for customer care configurator tools and service provisioing (example Voice over Wifi)
Essential for all IoT devices in order to support standardised device management mechanism for: - Service Configuration - Device Status - Maintenance - Alert-System - Data Records - Reports
High Q4 2018
High Q4 2017

N/A
N/A
http://m ember.o penmobi leallianc e.org/ftp /Public_ docume nts/DM/ Lightwei ghtM2M /Perman ent_doc uments/ OMA-TSLightwei ghtM2M -V1_0201702 08-A.zip (check for latest version)

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Observe parameters
Default Min/Max Period Resources of LwM2M Server Object
Multiple server access control

Support of the following Observe parameters: Minimum Period, Maximum Period, Greater Than, Less Than, Step, Cancel
The device shall support Default Min/Max Period Resources of the LwM2M Server Object. This is an alternative way of configuring periodic reporting - via the LwM2M Server Object instead via the "Write Attribute" command. The Access Control Object is required to manage access rights in a multiple server scenario.

High Q4 2017 High Q4 2017 Low Q1 2018

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Info Battery Level

The device shall provide Manufacturer, Model Number, Serial number, Device Type, and Hardware Version via the Device Object.
Expose the remaining battery level percentage via the Device Object

Med Q4 2017 High Q4 2017

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Available Power Sources, Power Source Current, Battery Status Memory Free and Memory Total

The device shall provide the Available Power Sources, Power Source Current, and Battery Status via the Device Object.
The device shall expose Memory Free and Memory Total via the Device Object.

Med Q4 2017 Med Q4 2017

Device Manage ment

OMA LwM2M

Error reset

The device shall support the Reset Error Code command via the Device Object.

Med Q4 2017

Device Manage ment

OMA LwM2M

Read/write device time

The device shall support read/write of Current Time, UTC Offset, and Timezone via the Device Object.

Med Q4 2017

Device Manage ment

OMA LwM2M

read APN

The device shall expose the currently used APN via the Connectivity Monitoring Object (this requirement is read-only).

High Q4 2017

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

http://m ember.o penmobi leallianc e.org/ftp /Public_ docume nts/DM/ Lightwei ghtM2M /Perman ent_doc uments/ OMATSLWM2M _ConnM gmtV1_1201702 01-D.zip (check for latest

Vodafone Group Products & Service

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

APN configuration
Lock and wipe

Exposure of APN configuration parameters via the APN Connection Profile Object. This is essential in case the device doesn't support the autoAPN feature. The device shall support lock and wipe commands via the LOCKWIPE Object.

Med Q4 2017 Med Q4 2017

Software

The device shall support software

Med Q1 2018

management management via the SWMGMT Objects.

LwM2M factory bootstrap
LwM2M OTA bootstrap
WLAN settings

The device shall support LwM2M factory bootstrap. Security credentials and LwM2M server address(es) are preconfigured on the device.
The device shall support LwM2M OTA (over-the-air) bootstrap over any supported bearer (not limited to SMS). OTA bootstrap is the alternative mechanism to factory or smartcard bootstrap. The device shall support configuration of WLAN settings via the WLAN Connectivity Object.

High Q4 2017 Med Q2 2018 Low Q4 2017

SMS settings
CoAP over TCP
CoAP over non-IP
Power Source Voltage

The device shall support configuration of SMS settings. The SMSC address can be configured via the Cellular Network Connectivity Object.
The LwM2M protocol stack shall utilize IETF CoAP (Constrained Application Protocol) as underlying transfer protocol over TCP.
The LwM2M protocol stack shall utilize IETF CoAP (Constrained Application Protocol) as underlying transfer protocol over 3GPP NAS non-IP transport. Expose the current voltage (mV) of the available power source e.g. battery via the Device Object

Low Q4 2017 Low Q4 2017 Low Q4 2017 Med Q4 2017

Radio Signal Strength and Link Quality
Radio Signal Strength and Link Quality for NB-IoT
Location (cellid)

Expose the Radio Signal Strength and Link Quality via the Device Object. Parameters are dependent on the bearer used (see OMA LwM2M 1.0).
Expose the NRSRP and NRSRQ via the Device Object

High Q4 2017 High Q4 2017

Expose the cell-ID via the Device Object High Q4 2017

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

version)

Vodafone Group Products & Service

Device Manage ment

OMA LwM2M

Location (long, Expose longitude, latitude, altitude of lat, altitude) device via the Location Object

High Q4 2017

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Firmware update
Sensor value

Enables "pull" of firmware update via the Firmware Update Object.
Exposes any sensor values via IPSO Object(s)

High Q4 2017. The Firmware Update Object may also be used for application file and configuration file transfer.
Medium Q4 2017

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

PSM timer
Active timer
Supported Power Saving Mode
Active Power Saving Mode
Serving PLMN Rate Control
APN Rate Control
eDRX parameters for NB-S1 mode TotalPacketsS ent counter
Priority transmission

Exposure of the Power Save Mode Timer via the Cellular Network Connectivity Object. AT command +CPSMS needs to be supported for this.
Exposure of Active Timer via the Cellular Network Connectivity Object. Active Timer (T3324) controls the time the device remains reachable after transitioning to idle state in case there is pending data from the network. Exposure of the supported Power Saving Modes (PSM, eDRX) via the Cellular Network Connectivity Object. This indicates which power saving modes (PSM and/or eDRX) are supported by the device. Exposure of the Active Power Saving Modes (PSM and/or eDRX) via the Cellular Network Connectivity Object. This indicates which power saving modes (PSM and/or eDRX) are currently active. Exposure of Serving PLMN Rate control via the Cellular Network Connectivity Object. Only for when using signalling radio bearers (c.f. data over NAS), it indicates the maximum the number of allowed uplink PDU transmissions per time interval aggregated across all PDN connections. +CGCONTRDP needs to be supported for this. Exposure of APN Rate Control via the APN Connection Profile Object. Determines the number of allowed uplink PDU transmissions per time interval per APN. +CGAPNRC needs to be supported in order to provide this functionality. Exposure of Extended DRX parameters (Paging Time Window and eDRX value) via the Cellular Network Connectivity Object.
Exposure of TotalPacketsSent via the APN Connection Profile Object. Rolling counter for total number of packets sent via this interface since last device reset. ExceptionDataReportingAllowed exposure via the NAS Configuration Object. Enables the device to use the `exception data' mode for priority transmission.

High Q4 2017 High Q4 2017 High Q4 2017 High Q4 2017 Med Q4 2017
Med Q4 2017 High Q1 2018 Med Q4 2017 High Q4 2017

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

Device Manage ment

OMA LwM2M

NAS configuration
CoAP parameters configuration
PDN type control
Bearer selection
Acceptable RSRP, RSSI, RSCP for network selection Higher Priority PLMN Search Timer
Attach without PDN connection
Maximum uplink/downli nk packet size
Disable radio
Read/update PLMN list
LwM2M Server SMS Number

Exposure of NAS (Non-Access Stratum)

configuration parameters via the NAS

Configuration Object (derived from

3GPP TS 24.368). It enables for

example:

- request

device to attach with IMSI

- set minimum periodic search timer

Exposure of CoAP parameters via the

Communications Characteristics

Object. In case CoAP default values

don't provide maximum

communications efficiency the

parameters can be changed via this

LwM2M Object e.g. may number of re-

transmissions.

Exposure of PDN Type via the APN

Connection Profile Object. Configuring

the device to select Non-IP, IPv4, IPv6,

IPv4v6.

Exposure of Preferred communications bearer via the Bearer Selection Object (e.g. 2G, 3G, 4G, NB-IoT Control Plane, NB-IoT User Plane, Cat-M)

Exposure of acceptable RSSI, RSCP, RSRP via the Bearer Selection Object. Provides guide to the application when performing "manual" network selection e.g. switch from GPRS to NB-IoT. Exposure of Higher Priority PLMN Search Timer via the Bearer Selection Object. Interval between periodic searches for higher priority PLMNs of the same country when camped on a visited PLMN, i.e. roaming scenario. Exposure of Attach Without PDN Connection via the Bearer Selection Object. Forces the device to either `attach with PDN connection' or `attach without PDN connection' (e.g. for SMS transport only). Exposure of Maximum Uplink/Downlink Packet Size via the Communications Characteristics Object. Enables the server to retrieve this information from the device e.g. no become aware of limitations on the control plane path. Furthermore, the server shall be able to set the Max uplink packet size on the device. Exposure of Disable Radio Period via the Cellular Network Connectivity Object. Time period for which the device shall disconnect from cellular radio (PS detach, CS detach if applicable). Exposure of Operator List, Operator List Mode, and List of available PLMNs via the Bearer Selection Object stored on the device.

Exposed via the LwM2M Security Object: MSISDN used by the LwM2M Client to send messages to the LwM2M Server via the SMS binding.

Med Q4 2017 Med Q4 2017
High Q4 2017 High Q4 2017 Medium Q1 2018 High Q4 2017 Med Q4 2017 Med Q4 2017
High Q4 2017 Med Q4 2017 Med Q1 2018

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Device Manage ment

OMA LwM2M

Raw Public Key mode of DTLS security

Support of Raw Public Key mode of DTLS (se OMA LwM2M 1.0)

Med Q4 2017

Device Manage ment

OMA LwM2M

X.509 Certificate mode

Support of X.509 Certificate mode for DTLS (see OMA LwM2M 1.0)

Med Q4 2017

Device Manage ment
Device Manage ment Device Manage ment
Device Manage ment
Device Manage ment
Device Manage ment
Device Manage ment
IoT

OMA LwM2M OMA LwM2M OMA LwM2M OMA LwM2M OMA LwM2M
OMA LwM2M OMA LwM2M General Requirements

Pre-Shared Key mode of DTLS security
BootstrapServer Account Timeout CoAP Protocol
DTLS security
Pre-Shared Key mode of DTLS security
SMS Bearer
UDP Bearer
Config IMSI exposure uratio n

Support of Pre-Shared Key mode of DTLS (see OMA LwM2M 1.0) . The following cipher suite is mandatory to support: TLS_PSK_WITH_AES_128_CCM_8. The following cipher suite is optional: TLS_PSK_WITH_AES_128_CBC_SHA2 56 Bootstrap-Server Account Timeout exposed via the LwM2M Security Object. The LwM2M Client MUST purge the LwM2M Bootstrap-Server Account after this timeout. The LWM2M protocol stack shall utilize IETF CoAP (Constrained Application Protocol) as underlying transfer protocol.

High Q4 2017
Med Q2 2018 Essential for M2M devices that support OMA lightweight

A secure channel between LWM2M client and server shall be secured by DTLS (Datagram Transport Layer Security)

Essential for M2M devices that support OMA lightweight

Support of Pre-Shared Key mode of DTLS with the following cypher suites: TLS_PSK_WITH_AES_128_CCM_8 and TLS_PSK_WITH_AES_128_CBC_SHA2 56 For all Cipher Suites using AES in an LWM2M implementation the hashing functions SHALL NOT be SHA-1. The use of SHA256 is recommended. An LWM2M client will negotiate with the LWM2M server the best method during the DTLS handshake for establishing the DTLS session. SMS Binding with CoAP shall be supported to allow LWM2M interaction via SMS bearer

Essential for M2M devices that support OMA lightweight
Essential for M2M devices that support OMA lightweight

UDP Binding with CoAP is mandatory to Essential for M2M devices that

allow LWM2M interaction via UDP

support OMA lightweight

bearer

The IoT terminal shall expose the IMSI to the end-user in the local device configuration UI to serve installation and troubleshoot purpose. The IMSI should not be exposed via SDK or other

For IoT Devices, it is a business requirement of the IoT team to have the IMSI displayed in the web-UI.

OMA Lightwei ght LWM2M 1.0 or later release OMA Lightwei ght LWM2M 1.0 or later release OMA Lightwei ght LWM2M 1.0 or later release
OMA Lightwei ght LWM2M 1.0 or later release OMA Lightwei ght LWM2M 1.0 or later release N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

means to 3rd party apps running on the device.

IoT

General

eCall eCall end to The eCall capable IoT device shall have Important to ensure the IVS does not N/A

Requirements

end

passed eCall end to end testing

perform PLMN registration after

conformance according to CEN/TS 16454, based on power-up.

testing

EN 15722, EN 16062 and EN 16072.

This is to ensure the IVS does not

perform PLMN registration after power-

up.

IoT

General

eCall re-

The eCall capable IoT device shall

It is important that a eCall only

N/A

Requirements

configuration support reconfiguration number to

device can be configured in an way

number

allow the user to re-configure the

that additionally to eCall also other

eCall-only module to a combined

IoT services are possible.

eCall/IoT service device.

IoT

General

Gener MT SMS to non Robustness of non-SMS device: The

Essential to ensure robustness of the N/A

Requirements al

SMS capable non-SMS capable IoT device shall

IoT device, the non-SMS device shall

M2M device

ignore incoming SMS (also

ignore SMS

concatenated).

IoT

General

Gener SMS PDU

The IoT module shall support the

Important to support SMS PDU mode 3GPP

Requirements al

mode

following SMS command in PDU mode based applications for IoT services 23.040

M2M

according to 3GPP 23.040 and 23.038

and

23.038

IoT

General

Gener SMS text mode The IoT module shall support the

Important to support SMS text mode 3GPP

Requirements al

following SMS command in text mode based applications for IoT services 23.040

M2M

according to 3GPP 23.040 and 23.038

and

23.038

IoT

General

Gener Time to first The IoT device shall provide an AT

For a IoT application it is important to N/A

Requirements al

Service at

command to allow applications to

check the status of the device, e.g.

M2M power on

check the "Service Registration" status whether device is attached to the

after device was powered on. See 3GPP network. Therefore an AT command

27.007 +CREG.

shall be able to e.g. read out

signalling messages as "attach

accept" before starting any other

actions.

IoT

General

Gener Time to first The IoT device shall provide an AT

For a IoT application it is important to N/A

Requirements al

Service at

command to allow applications to

check the status of the device, e.g.

M2M power on with check the "Service Registration" status whether device is attached to the

SIM-Profile

after device was powered on with

network. Therefore an AT command

change

changed SIM profile. See 3GPP 27.007 shall be able to e.g. read out

+CREG.

signalling messages as "attach

accept" before starting any other

actions.

IoT

General

Gener Transactional The IoT device shall be able to support Lower cost for end customer if SMS-t N/A

Requirements al

SMS support transactional SMS messaging and the used rather than having to send

M2M

associated AT-command set.

ACK/NACK with dedicated

acknowledge-SMS. Instant feedback

about command execution success.

IoT

General

Gener Voice call with The IoT device shall support voice calls It is planned to deploy also voice

N/A

Requirements al

GDSP SIM

when GDSP SIM card is inserted. This functionality to the GDSP. The

M2M

requirement includes also Emergency support of voice calls is important for

calls.

IoT applications, e.g. elevator

emergency calls

IoT

General

Registr Blank APN

When used with a regular VF-operator Eliminating the need for device

N/A

Requirements ation connect

SIM: A database of Vodafone APN

configuration. Allowing near plug-

settings is stored on the device and will and-play performance

be used to determine the correct

configuration.

When using a VF GDSP/IoT SIM the

device supports the APN assignment

from the backend.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

IoT

General

Registr Graceful

Upon registration rejects, the device To prevent devices from creating

N/A

Requirements ation backoff if SIM will exponentially back-off from

excess signalling from failed

suspended

registration attempts until a maximum registration attempts if the SIM was

wait time of 20 minutes. Then the

customer-deactivated on the VF IoT

device will flush any network blacklist platform GDSP.

to allow a fresh cycle (e.g. power cycle

after 20 minutes or appropriate). The

max back-off time needs to be

remotely configurable.

IoT

General

Roami Fall-back

The device shall detect the presence of For extension of the current preferred N/A

Requirements ng

roaming

a GDSP SIM and in that case execute an network list functionality to allow for

alternative roaming algorithm based use of global roaming SIMs where

on a text or XML file of carriers. The

large numbers of overlaid and

typical size of this file is 500 entries.

adjacent roaming networks may be

The text file needs to be remote

encountered. Secondly to be able to

updateable e.g. by administrable SMS, optimise the roaming behaviour of

TR-069, OMA LwM2M.

IoT devices to always chose the most

cost efficient and reliable network.

IoT

General

SMS SMS to GDSP When using the GDSP SIM the device is When using the VF IoT SIM the VF IoT N/A

Requirements

shortcode

able to send SMS to GDSP shortcode platform GDSP need to be used to

numbers e.g. 310000214.

send and receive SMS. Devices are

not addressable by their MSISDN.

IoT

General

Wakeu Dial-in on

Device can automatically establish an Primarily for fixed-router

N/A

Requirements p

demand /

active PDP context upon receiving a

replacement devices, this feature is

wakeup on

trigger (activity) from the connected required to allow automatic response

LAN

host application through the LAN

to requests from LAN-side

connection on the ethernet port.

equipment to establish a PDP

Device will check if the IP range of the context for WAN transfer of those

data packet is outside it's own routing packets.

area and in this case establish a

connection.

IoT

General

Wakeu Hold time on Configurable hold time for active but If not supported, could result in

N/A

Requirements p

LAN wakeup data-idle PDP context after LAN

devices holding session indefinitely,

wakeup. (i.e. How long will the device or constantly raising and lowering

continue to "listen" for incoming data PDP context hold resources or

before going back to simple GPRS

generate excessive signalling.

attach again).

Excessive signalling can result in a

network incident event.

IoT

General

Wakeu Hold time on Configurable hold time for active but If not supported, could result in

N/A

Requirements p

SMS wakeup data-idle PDP context after receiving devices holding session indefinitely,

wakeup. (i.e. How long will device

or constantly raising and lowering

"listen" for incoming data before going PDP context hold resources or

back to simple GPRS attach again).

generate excessive signalling.

Excessive signalling can result in a

network incident event.

IoT

General

Wakeu SMS wakeup Device can wake up from simple GSM If not supported, the device will not N/A

Requirements p

and GPRS attached state and establish be compatible with the Vodafone IoT

an active PDP context upon receiving Service operating characteristics.

an SMS from the GDSP platform. Device Integrator of a device will have to

needs to listen to an empty class 1 SMS develop their own wakeup scheme

from a predefined, configurable

over and above the device, exposing

number.

the device to potentially negative

operating conditions.

IoT

PDP context Authe PAP/CHAP

The IoT device shall support PAP

PAP and CHAP are authentication

N/A

handling

nticati

(Password Authentication Protocol)

protocols used to authenticate a user

on

and CHAP (challenge handshake

to a server.

Authentication Protocol)

IoT

PDP context PDP Simultaneous The IoT device shall support

Simultaneous primary APN are

N/A

handling

contex PDP contexts simultaneous PDP contexts as follow: essential to support device

t

It shall be capable to support two

management via TR69 and IoT

simultaneous PDP contexts to the

services.

same APN, one for device management

(OMA LwM2M, TR.69) and one for

services.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

IP

General

Protocol Requirements

IP

General

Protocol Requirements

IP

General

Protocol Requirements

IP

General

Protocol Requirements

IP

Security

Protocol Requirements

IP

General

Protocol Requirements

DNS Requir ement s
IP Requir ement s

DNS Server Address
Dual IP stack

IP Requir ement s

IPv6 Interface Identifier

IPv6 IPv6 Application

HTTP Generi c Requir ement s

Support for GBA for establishing TLS and DTLS connections

IPv6 MMS over IPv6

The terminal shall use the DNS server Resolve IP addresses from names. N/A

address noticed by Activate PDP

Non-compliance breaks everything

Context Accept.

A dual IPv4/ IPv6 stack shall be supported for application user plane and for control plane. The LTE UE must also be able to support simultaneous PDN connections to different APN and IP version . The terminal is required to support IPv4 and IPv6 PDP contexts as follow: 1- It shall be capable to request and support a dual address PDP context according to 3GPP R8 (PDP Type value Hex 8D). 2- It shall be capable to support two simultaneous primary PDP contexts to the same APN, one with PDP Type IPv4 and one with PDP Type IPv6. 3- It shall be capable to fallback to (2) if (1) results in a single IP address being allocated with SM cause #52 'Single address bearer only allowed' or if (1) results in a successful PDP Context activation with address IPv4. When the device generates its own interface identifiers rather than using interface identifiers provided by the network, the interface identifier shall be randomly generated for each new IPv6 address required (except for linklocal addresses) in compliance with 3GPP TS 23.221 and IETF RFC 4941. The device shall not use any pre calculated / embedded data to compute a static post-fix (e.g. not IMEI, not IMSI, not MSISDN, not ICCID, not MAC) . IPv6 shall be also handled by the application layer. This is particularly requested for a closed OS. Applications should prefer IPv6 over IPv4 if there is a choice The device HTTP stack shall support GBA for establishing TLS and DTLS connections according to 3GPP TS 33.222.
MMS shall operate over IPv6

This is essential for LTE and especially VoLTE Terminals as our APN strategy is based on IPv6.
This is to ensure that the PDP context is setup correctly. Failure to do this will result in connection issues for APNs. Device must not be trackable.
IPv6 support needed for all internet connections
Required for establishing a secure connection from the device to an application server.
IPv6 support needed for all internet connections

N/A
3GPP TS 23.221 IETF RFC 4941
N/A
http://w ww.3gpp .org/ftp/ Specs/h tmlinfo/332 22.htm N/A

IP

SIP-IMS

Protocol

Gener al Requir ement s

Standards Compliance

The SIP/IMS implementation shall be compliant with the following Specifications and Referenced Specifications. Non compliance to the standards shall be highlighted in details.

Standards compliance

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

latest approve d releases of 3GPP TS 23.228, 3GPP TS 24.229, OMA Standard

Vodafone Group Products & Service

s for IMS

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IMS Client Upgra de
IMS protoc ol stack

Configuration Managed Object
List of SIP methods supported

IMS protoc ol stack
IMS protoc ol stack

Open API for SIP stack
Single SIP stack

IMS protoc ol stack

SIP stack framework

QoS Authorizaton Manag Token ement Handling

The terminal shall support

Device management. This is needed N/A

configuration by the network using the e.g. for provisioning of the VoWiFi

OMA CP Application Characteristics

service of VF UK.

specified in 3GPP TS 24.167

The terminal shall support the following SIP methods:

we need to have a clear view of all N/A the SIP methods supported.

REGISTER/INVITE/ACK/BYE/CANCEL/ SUBSCRIBE/NOTIFY/PUBLISH/REFER/ UPDATE/PRACK/OPTIONS/MESSAGE The IMS stack shall support open API in Important for VoLTE client behaviour N/A order to allow 3rd Party IMS services to use the IMS Framework.

A single SIP stack - which is part of the OS - shall be implemented by the device and used by all the relevant applications (VoLTE, RCS, other Apps). No other SIP stack shall be accessible by any applications. The VoLTE UE shall have a single IMS Stack Framework including SW and Modem in order to run IMS services (VoLTE, SMSoIP, VT, etc) as well as RCS. The common IMS stack shall allow dual registration: In current implementation a device provides both RCS and VoLTE clients as completely separate implementations, the RCS client shall behave as a nonembedded client and shall consider the device to be in RCS-CS mode whenever in cellular coverage. Meaning that for the first years of VoLTE deployments it is assumed that the single stack will be capable of issuing one registration for VoLTE services and another registration based on ACS data for RCS service. In order to properly perform in Vodafone network and guarantee user experience as appropriate, a UE activating or updating a secondary PDP context SHALL always populate the TFT filters with at least the following information when TFT operation is `create new TFT', `add packet filters to existing TFT' or `replace packet filters to existing TFT': - source IP address (IPv4 or IPv6) - source port (single or range), if available to the UE - destination port (single or range)

important for security and efficiency. The 3GPP compliant SIP stack has to have low level integration in order to support the necessary security mechanism. Important for VoLTE client behaviour
Non support means handset multiplexing media flows (of different media components/sessions) on the same transport port number will not enable the Vodafone network (i.e. EPDF) to identify the appropriate policy to apply. This will result in: - the UE not gaining QoS resources from the network; and - the user being potentially wrongly charged since it is not possible to differentiate between media flows.

N/A
GSMA joyn Blackbir d Product Definitio n Docume nt Version 1.1, Table 2: RCS Device Modes
3GPP TS 24.008

In case of SIP/SDP (IMS) and RTSP (Streaming), the UE SHALL derive the above listed packet filters information from the application signalling exchanged between end points

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

Securi ty
Securi ty
Suppo rt for IMS service s Transp ort Netwo rk and IP conne ctivity
Transp ort Netwo rk and IP conne ctivity Suppo rt for IMS service s
Suppo rt for IMS service s
Suppo rt for IMS service s
Suppo rt for IMS service s
Suppo rt for IMS service

API's access
Full IMS security solution 3GPP
Codecs accessibility
Overriding configurations from the network.
ROHC support
Support of "anonymous" Emergency Call for S8HR VoLTE roamers
Support of ICSI service tag
CS fallback when "IMS" APN is not included in the Subscription profile
Provide the last cell-id information under VoWiFi in an emergency INVITE Provide the GPS location co-ordinates (longditue and

The access to the API's SIP/IMS stack shall be dependent on application authorisation level and be configurable by Vodafone.
Full IMS security mechanism The terminal shall support the full IMS security mechanism defined in the latest approved release of 3GPP TS 33.203. Any non compliances to the TS should be clearly specified. All speech/video/audio codecs supported by the terminal shall be accessible by the IMS clients.
The terminal SHALL accept overriding configurations from the network i.e., it SHALL, upon PDP establishment, accept suitable DHCP extensions to set its hostname to one sent from The network. This override may come from The DHCP or AAA servers depending on local architecture restrictions. ROHC (RObust Header Compression) shall be supported as defined in 3GPP TS35.206 and RFC3095 and RFC 4815.
If the UE receives a SIP 403 (Forbidden) as a response of an IMS Emergency registration attempt, the UE must attempt an unauthenticated IMS emergency session request (INVITE) including an "anonymous user" parameter in the SIP INVITE message. VoLTE devices must populate the ICSI service tag "urn:urn-7:3gppservice.ims.icsi.mmtel " in the SIP Invite to indicate they wish to establish a VoLTE call for originating calls, and in the SIP response (183, 200) to indicate they are ready to accept a VoLTE call for terminating calls. Under outbound roaming, if the UE receives a "PDN Connectivity Reject" from MME with cause code "Unkown APN" when it asks for a PDN connection with the IMS APN (due to the fact that IMS APN is not in the Subscription profile for the specific VPLMN), the UE shall perform a CS Fallback and shall not ask for an IMS PDN connection again until it changes VPLMN. Under VoWiFi and when the UE sends an emergency INVITE, it shall include the last cell-id information used under 4G. This is needed from the network in order to route the emergency call to the proper PSAP.
Under VoWiFi and when the UE sends an emergency INVITE, it shall include the GPS co-ordinates. This is needed from the network in order to route the

Security and business control, Vodafone can control which applications can use the IMS infrastructure: might be hard to implement. Supported in Java. This relates to Ipsec support. The interim security solution is the bottom line. Vendors should support this security solution.
IMS applications being able to make use of all the device content/format.
Important for IPv6 communication (AAAA response)
Necessary for IPv6 header compression. Saves bandwidth and transfer speed of packets. But it is not currently supported on the network side.
This allows VoLTE Emergency calls when Roaming
This allows VoLTE Supplementary Services execution.
This is a requirement to enable VoLTE Roaming restriction from the Home Network in the S8HR VoLTE Roaming.
This is a requirement to enable VoWiFi Emergency calls and to comply with relevant regulations.
This is a requirement to enhance VoWiFi Emergency calls and to comply with relevant regulations.

N/A 3GPP TS 33.203 N/A N/A
N/A N/A N/A
N/A
N/A N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

IP

SIP-IMS

Protocol

IP

SIP-IMS

Protocol

IP

General

Protocol Requirements

IP

LTE

Protocol

Local Bluetooth Connect Requirements ivity
Local Bluetooth Connect Requirements ivity
Local Bluetooth Connect Requirements ivity
Local Bluetooth Connect Requirements ivity
Local Bluetooth Connect Requirements ivity

s

latitute) under

VoWiFi in an

emergency

INVITE

Suppo rt for IMS service s

Support of UE undetected emergency calls under S8HR roaming

Suppo rt for IMS service s
4G enhan cemen t

Support of network provided emergency number list in S8HR VoLTE Roaming. Named APN per UE App (Android and iOS)

VoLTE

VoLTE roaming: IPv4/IPv6 support for APN IMS

Gener al Blueto oth Requir ement s Gener al Blueto oth Requir ement s Gener al Blueto oth Requir ement s Gener al Blueto oth Requir ement s Gener al Blueto oth Requir ement s

Bluetooth 5.0
Bluetooth 4.2
Bluetooth 4.0
Bluetooth Certification
Bluetooth Factory Settings

emergency call to the proper PSAP.

In the case of an S8HR UE undetected This is a requirement to enable S8HR N/A

emergency call (SIP INVITE towards the Roaming VoLTE Emergency calls.

Home PLMN), the UE shall understand

the SIP 380 redirect response from the

Home P-CSCF and either perform an

emergency call in CS in the Visited

network or an unauthorized

emergency call in VPLMN with

emergency Registration.

The UE shall support the emergency This is a requirement to enhance

N/A

number list provided by the MME

S8HR VoLTE emergency calls by

during attachement in the S8HR

reducing the time for setting up an

Roaming case. This list shall be used emergency call when using the

for emergency call detection and shall visited network's emergency number

be discarded upon attachment to

list.

another VPLMN.

Any terminal application (on Android, This allows scenarios for e.g. Low

N/A

iOS, etc) should be able to use a named Latency and Enterprise services

APN (e.g. gaming app to use a "low

based on dedicated NW core

latency APN")

resources

The UE must support both IPv4/Ipv6 already

N/A

for IMS APN.

The requirement is aplicable both for

4G and 5G devices when the 5G

devices are under Opcion 3x handling

the voice over LTE

The terminal should support Bluetooth Bluetooth 5.0 offers enhanced data

5.0

rates. Bluetooth 5.0 should be

supported by high tier terminals.

The terminal shall support Bluetooth Bluetooth 4.2 offers more resilient N/A

4.2

connections and improved battery

performance. This is the minimum

requirement for 4G smartphones.

The terminal shall support Bluetooth 4.0

The main improvement in Bluetooth 4.0 is the low energy support. This is the minimum requirement for entry phones, 3G smartphones and accessories.

The terminal shall pass tests and obtain Part of the Bluetooth certification

N/A

certification for Logo authentication process - logo cannot be used

defined by BQTF (Bluetooth

otherwise. Terminal could potentially

Qualification Test Facility ).

not support the Bluetooth standard.

Testing must be carried out by a certified authentication institution. Factory settings shall be as follows: - Bluetooth shall be turned off as default. (see note below) - Bluetooth shall be set to nondiscoverable as default

If not supported, the terminal will be N/A in the state where Bluetooth is already activated at the time of terminal purchase. Therefore, security is not maintained.

These default settings shall be stated in the user manual, along with information regarding potential

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Local Local

Connect Connectivity

ivity

Requirements

Data securit y and privac y

Activity Notification

Local Local

Connect Connectivity

ivity

Requirements

Data securit y and privac y

Connection Request Confirmation

Local Local

Connect Connectivity

ivity

Requirements

Local Local

Connect Connectivity

ivity

Requirements

Data securit y and privac y Data securit y and privac y

Inbound connection management
Wireless connection integrity

Local Local

Connect Connectivity

ivity

Requirements

Device Softwa re Upgra de Suppo rt

Local SW upgrade

security risks.

nb:

Turning Bluetooth on shall NOT

automatically set the state as being

discoverable

In any case, whether wireless or wired, Without a notification, an application N/A

the device shall display an indication to could cause chargeable events for

the user eg

the user.

'Connecting...."/"Connected", "Sending

message..." etc. LED indication shall be

available for devices without display.

Although Bluetooth is the main threat,

IrDA to a lesser extent (as it requires

Line of Sight to connect), there is still a

potential threat from using a wired

cable connection. Although the user

physically connects to another device

eg laptop, there is still a threat from

malicious code running on the

connected device that may trigger

chargeable events.

The device shall prompt the user via Usability and security.

N/A

device display or WEB interface for

terminals without display when a

Wireless 'connected' device is

requesting connection to it. (ie over

BT). The

Eg, the requesting device may be requesting a connection to the network to make a chargeable to make a connection to the network (eg SMS, MMS, VT Call, Voice Call etc.)

The user shall be given the option to switch the request off: eg - Permanently (ie never ask), - Per Session (ie ask once per connection), or - Always (always ask).

The user shall be able to configure

connected devices profiles individually

ie allow certain devices full access,

others that must prompt the user.

WiFi: When connected to a wireless

Non compliance may result in

N/A

network, the device shall not allow a exposure to security vulnerabilities,

listening port to accept inbound

causing possible breach of data

connections to view the terminal, file protection.

system or registry.

Any access to the terminal via

Non-compliance leaves data

N/A

manufacturer supplied management transferred to and from terminal over

tools over WiFi or Bluetooth, must be WiFi and Bluetooth open to

made over an authenticated and

interception by a third party.

encrypted connection.

The authentication method used may

include use of random or user

generated passcodes.

For security reason, It shall NOT be

This prevents core terminal software N/A

possible to upgrade the SW of the

being replaced via Bluetooth/IrDA.

device by connecting it to an external

device (eg PC) via bluetooth or IrDA,

but it shall be possible through USB

cable, or other Vodafone approved

methods (e.g. OMA DM).

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Local Local

Connect Connectivity

ivity

Requirements

Local Local

Connect Connectivity

ivity

Requirements

Local Local

Connect Connectivity

ivity

Requirements

Local Local

Connect Connectivity

ivity

Requirements

Local Modem Connect ivity
Local MTP Connect Requirements ivity

Mode m and PC suppor t Mode m and PC suppor t PC Backu p/Syn chroni sation Wirele ss Office & Dashb oard Requir ement s Data access to PC
MTP Specifi cation

USB Tethering Support
Wi-Fi Tethering Support
PC Sync
AT Commands Specification
Simultaneous APN PDP Contexts Device Stage metadata

The Terminal shall support USB Tethering
The Terminal shall support Wi-Fi Tethering (or Hotspot Wi-Fi or Router Wi-Fi)
The terminal shall support synchronisation of Contacts and Calendar with a PC. Appropriate software shall be included with the terminal. The terminal shall be compliant to all mandatory parts of 3GPP TS 27.005 and TS 27.007.
The device shall support simultaneous PDP contexts to different APNs (and not allow multiple PDP contexts to the same APN in order to preserve network resources) The Device Stage metadata corresponding to each Vodafone Model ID shall be customized according to Vodafone requirements.

Enhance data usage

N/A

Enhance data usage

N/A

If unsupported it becomes

N/A

impossible for user data, such as a

telephone directory and a scheduler,

to take a synchronization between a

terminal and PC.

Important for phones to be able to N/A

access all the relevant AT commands

specification

Mandatory to allow the user to make N/A use of all devices applications while data modem is active.
Device Stage Metadata is for when N/A the device is connected to a Windows 7/8/10 PC via USB. Automatic meta data is loaded based upon the Vodafone Model ID.

Local MTP Connect Requirements ivity
Local MTP Connect Requirements ivity
Local USB Connect Requirements ivity
Local USB Connect Requirements ivity
Local USB Connect Requirements ivity

Essential to leverage Vodafone

experience and services.

MTP Model ID

The terminal shall implement an

Essential for customized Device

N/A

Specifi customization unique Vodafone Model ID value for

Stage experience for Vodafone

cation

each device model. For which of the

Operating Companies or Partner

Networks the Vodafone ModelID shall

be supported will be indicated at each

device project level.

MTP Model ID

The terminal shall implement the

Essential for customized Device

N/A

Specifi support

Model ID (128-bit GUID) property

Stage experience for Vodafone

cation

according to the MTP Device Service

Extension specifications.

Gener al USB Requir ement s
Gener al USB Requir ement s
Gener al USB Requir ement s

USB Cable and Connector USB support
USB-on-the-Go

Device shall support a USB Type-C connector (for legacy devices USB Micro connector is acceptable) (to be connected to a power plug or PC).
The terminal must provide a wired USB connection.
The USB port preferably should support USB 3.0. As a minimum it must be compliant with USB 2.0 and maintain backwards compatibility with previous versions. The terminal shall support USB-on-thego devices like a USB mouse, USBexternal-harddrive, USB-Keyboard, USB-Memory Stick and it shall be possible to use the USBotG with the

Connections must meet the relevant standard to allow interoperability between devices.
Required for USB connectivity.
Important for Smartphones to use on-the-go accessory. Essential for Tablets to use on-the-go keyboard.

http://w ww.usb. org/dev elopers/ usbtype c/ http://w ww.usb. org/dev elopers/ docs/
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

terminal.

Local USB

Securi Require device All devices should prompt end user to To prevent access to device USB

N/A

Connect Requirements ty

unlock

authenticate using Activesync

mass storage or internal memory,

ivity

enforced pass code to access device without unlocking the phone.

prior to connecting device to laptop for

synchronising data and services.

Only if the activesync Device Lock

security policy is enforced, any options

in the device menu which control the

behaviour of the phone when

connected via USB cable to a PC, shall

be defaulted to provide a prompt to the

user and defaulted to "charge only"

mode if no action is taken. This will

enforce the user to unlock the phone

with required pass code in order to be

able to access the selection prompt,

where "USB Mass Storage", "Internet

Sharing" or "PC Suite" can be selected.

Also, the options in the device menu

which control the behaviour of the

phone when connected via USB cable

to a PC, must be greyed out and

unchangeable by the user.

NOTE: On Android, "USB debugging"

must also be unticked and greyed out

as long as the activesync Device Lock

security policy is enforced.

Local USB

USB Maintenance Maintenance Mode(A tool which can Vodafone want the protocol

N/A

Connect Requirements Profile Mode via USB take the logs of sequences between messaging log for testing. This tool

ivity

s

the terminal and the network as well as shall operate via USB I/F.

radio parameter) shall be provided by When terminal cannot support this

the USB connection.

function, then we need to check

whether the handset vendor can

provide the emulator tool.

Local VPN

Techn VPN

The terminal shall support the creation Enabling connection to a private

N/A

Connect

ology

of VPN connectivity.

network.

ivity

Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity

Authe nticati on
Authe nticati on
Authe nticati on
Authe nticati on

Authentication when device is acting as a host

The devices authentication (WPA/WPA 2) shall be available when acting as a host device i.e mobile hotspot mode.

EAP-AKA Authentication
EAP-SIM authentication

The device shall support EAP-AKA authentication (as specified in RFC 4187) or EAP-AKA' (as specified in RFC 5448 and 3GPP TS 33.402) with IKEv2 key exchange (as specified in RFC 7296) The device shall support EAP-SIM authentication, as described in RFC 4186

WPA2

The device shall support WPA2 (Personal and Enterprise) encryption

Increased security authentication

N/A

when device is being used as a

personal hotspot.

EAP-AKA or EAP-AKA' authentication N/A mechanism is required as part of the WiFi Calling (VoWiFi) solution. Without this the terminal can not connect to Wi-Fi

Ensure implementation according to N/A

standards

Essential authentication mechanism

for all devices that have Wi-Fi Offload

capability. For Wi-Fi Calling (VoWiFi)

EAP-AKA will be required in place of

EAP-SIM.

WPA2 provides better security of

N/A

connection for WiFi connections than

WEP and WPA. Should be supported

for all terminals with WiFi.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Local WLAN Connect ivity

Authe WPA-PSK

The device shall be able to connect to Allow connection to host devices

N/A

nticati Authentication a secure WLAN network using the WPA- using WPA-PSK authentication key.

on

PSK authentication key.

Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity

Gener al Requir ement s Gener al Requir ement s

802.11k Support
802.11r support

Gener al Requir ement s

Auto-Join

All devices should support 802.11k where the OS allows it. The device should ALWAYS have this enabled by Default whether it is in software (hidden) or selectable on the UI. All devices should support 802.11r using Fast Basic Service Set Transition (FT) where the OS allows it. The device should ALWAYS have this enabled by Default whether it is in software (hidden) or selectable on the UI. Terminal SHALL allow user to override automatic WLAN network selection function for EAP-SIM and EAP-AKA OpCos pre-installed profiles (listed in VVS). The user must be able to disable automatic connection (auto-join) to only one or more individual EAPSIM/AKA WLAN access points, without affecting automatic connection to other available access points.

VF UK is looking to launch EAP SIM Wi-Fi for London Underground, the Service will aim to use 802.11k to reduce network load from authentications VF UK is looking to launch EAP SIM Wi-Fi for London Underground, the Service will aim to use 802.11r to reduce network load from authentications
To ensure Auto-Join can be selected/deselected by the user. Essential for VF UK OpCo in relation to EAP-SIM.

N/A
N/A
EAP_SIM _VFUK_ v1.3_Iss ued.pdf

Also, the OpCos pre-installed EAP-SIM

and EAP-AKA profiles must be "read-

only", and it must not be possible for

the end user to Delete permanently

one or all the pre-configured profiles,

i.e., the options to "Forget/Delete" or

"Modify" them shall be removed.

Gener Automatic

If the terminal is capable to perform

Protect device resources (e.g.

N/A

al

Scan

automatic scan on WLAN network;

Battery)

Requir

1. the terminal shall not be set on

ement

automatic search as default.

s

2. the user shall be able to disable the

automatic search of new network

Gener al Requir ement s Gener al Requir ement s

Captive portal
EAP - New Access Point Connections

Gener al Requir ement s Gener al Requir ement s

Hotspot2.0 IEEE 802.1X

However the device should offer the

user during first time start up sequence

the option to turn WLAN on and

perform a search

Terminal SHALL provide user with a

Device needs to know that a captive N/A

notification that log-in to a captive

portal log on is needed

portal is required

Device should not connect to new Wi-Fi access points while the screen is off or in standby
The terminal shall be HotSpot certified against Wi-Fi Alliance Passpoint
The terminal shall support IEEE 802.1X

Required for EAP-SIM Programmed AP's (e.g., 'Auto-BTWiFi'). To avoid high load of authentication servers on the network. Essential enabler for WiFI Calling (VoWiFi) feature A minimum of Passpoint Release 1 features is required. For release 2 features Online singup is not a priority and operator policy should be delivered via ANDSF. Important for Data offload

N/A
Hotspot 2.0
IEEE 802.1X

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity

Gener IPv6 over

If WLAN is supported, IPv6 shall be

Will impact consistent access to IPv6 N/A

al

WLAN

equally possible via WLAN / Wi-Fi

services

Requir

ement

s

Gener Maintain

Terminal SHALL be able to maintain This is required to enable support of N/A

al

simultaneous cellular and Wi-Fi connections

separate IP flows distributed on

Requir Wi-Fi and

simultaneously

cellular and Wi-Fi (REF: GSMA PRD:

ement Cellular

TSG22_CM_13). Essential for WiFi

s

connections

Calling propositions

Gener Minimum

When being used as a Wi-Fi Hotspot the Failure to comply will lead to poor N/A

al

simultaneous terminal shall support a minimum of level of accessibility for many users

Requir connections 10 simultaneous connections.

ement

s

Gener PMIP

Support of IP session persistence

To support Wi-Fi deployments

N/A

al

between operator configured WiFi and

Requir

operator's 3G/LTE networks using PMIP

ement

with IP address anchored at HA.

s

Gener VPN Auto Start In case device is connected to an open, Ensures user data can be secured via N/A

al

untrusted Wi-Fi network, the device

VPN

Requir

shall have the capability to configure to

ement

start automatically a VPN client to an

s

Enterprise or the Vodafone

infrastructure.

Gener Wi-Fi

Terminal SHALL implement a

Considering Wi-Fi link quality can be N/A

al

hysteresis

hysteresis mechanism to avoid

varying quickly, client should not

Requir

connection to/disconnection from the keep disconnecting and connecting

ement

same Wi-Fi AP within a minimum time to the same Wi-Fi AP. REF: GSMA PRD

s

interval to be configured by operator TSG22_CM_56

Gener Wi-Fi

Terminals SHALL support provisioning The operator SHALL be able to

N/A

al

Provisioning with priorities and/or thresholds

override default priorities and/or

Requir

related to RSSI, BSS load information, thresholds (outlined by requirements

ement

PasspointTM WAN metrics information 1 and 2) using proprietary means e.g.

s

and minimum Wi-Fi data throughput Operator can use proprietary

level e.g. pre-configured or as part of Management object (XML file

operator policies.

download) to push values for

configurable thresholds and/or

priorities, or, for IoT Devices the

LwM2M standard my be used.

Note that the acceptable quality of

service threshold for WiFi Calling and

Messaging services will need to be

managed in addition to this basic

connectivity requirement

Essential for management of WiFi

connections for WiFi Calling (VoWiFi)

Gener Wi-Fi

Terminals SHOULD use provisioned

If there is pre-configured minimum N/A

al

Provisioning priorities and /or thresholds by the

throughput policy by the operator

Requir Priority

operator, when present, with higher

the default terminal implementation

ement

priority than default manufacturer

value shall not be used.

s

priorities/thresholds.

Gener Wi-Fi Quality - Terminals SHALL consider the

Terminal may have its default

N/A

al

Association

following parameters, when available, minimum RSSI threshold or this

Requir

in selection of a Wi-Fi AP, based on

threshold can be

ement

default priorities and/or thresholds for preconfigured/provisioned by the

s

those parameters specified by the

operator in the terminal. A minimum

manufacturer:

threshold of -85dBm is

- Wi-Fi RSSI

recommended. This is to ensure the

- IEEE 802.11 BSS load IE

terminal only connects to quality

- PasspointTM WAN Metrics IE

Access Points.

Note that the acceptable quality of

service threshold for WiFi Calling and

Messaging services will need to be

managed in addition to this basic

connectivity requirement

Essential for WiFi connection

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

management for WiFi Calling

Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity

Gener Wi-Fi Quality Once associated with a Wi-Fi AP,

Terminal may have its default

N/A

al

Monitoring

Terminals SHALL monitor the following minimum RSSI threshold or this

Requir

parameters when evaluating whether threshold can be

ement

to disassociate and switch back to the preconfigured/provisioned by the

s

3GPP network based on default

operator in the terminal. A minimum

priorities and/or thresholds for those threshold of -85dBm is

parameters specified by the

recommended. This is to ensure the

manufacturer

terminal only remains on good

- Wi-Fi RSSI

quality Access Point.

- Data throughput

Essential for WiFi Calling (VoWiFi)

- Latency

connection management

Gener Wi-Fi retry limit The terminal SHALL limit the number Important that the client does not N/A

al

of access retries to the same Access keep retrying Wi-Fi access after it is

Requir

Point when it receives temporary

denied access. REF: GSMA PRD

ement

denied access notification from that TSG22_CM_57

s

Access Point.(as e.g. RFC 4186 1026

notification with EAPSIM)

Gener WLAN -

Wi-Fi should be set to 'Always on' when Where implementation allows, we

N/A

al

Screen

Screen is switched off to avoid bill

should ensure that the default is to

Requir Timeout

shock.

leave Wi-Fi on when the screen

ement

times-out or is switched off by the

s

user.

Securi SSID

The device shall be able to connect to Allow connection to networks with N/A

ty

a wireless device which has its SSID

SSID hidden

hidden.

Securi WLAN Security The device shall be able to connect to Allow connectivity to networks with N/A

ty

insecure WLAN networks that require no security key enabled

no security key to connect. The device

should display a security warning

when associating with an insecure

SSID.

Securi WPS Key

To prevent WPS Key bruteforce attacks To implement lock out policy for

N/A

ty

Timeout for being attempted easily by connecting WPS key brute force attempts.

bruteforce

devices the device firmware will

Security implications.

attack

provide the ability to track the

prevention

attempted incorrect WPS Key entries.

Should the "user" enter the WPS Key

incorrectly 3 times in succession the

device will not accept any further WPS

Key entries for a initial configurable

interval. The default value for the

interval will be one minute with each

increment being a further interval (one

minute) + the previous countdown

time. For Example

Incorrect Attempt 1

Incorrect Attempt 2

Incorrect Attempt 3

//Timer Waits 1 Minute

Incorrect Attempt 4

//Timer Waits 2 Minutes

Incorrect Attempt 5

//Timer Waits 3 Minutes

Incorrect Attempt 6

//Timer Waits 4 Minutes

Upon a WPS key being entered

successfully or the device rebooted

then the WPS Key timer and counter

will reset again.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Local WLAN Connect ivity
Local WLAN Connect ivity

Standa 5GHz Wi-Fi rds

The terminal shall support Wi-Fi in the Important especially for high tier

N/A

5Ghz band

smartphone/tablets to allow users

increased data speeds over WiFi.

Essential for WiFi Calling (VoWiFi)

Standa IEEE Standard The WLAN terminal shall comply with Offers increased speed and Wi-Fi

N/A

rds

the IEEE 802.11 b/g, 802.11 N and N- range

MIMO standards.

Local WLAN Connect ivity

Standa Wi-Fi 802.11ac The WLAN terminal shall comply with Important to offer increased speeds N/A

rds

the IEEE 802.11ac standards.

over Wi-Fi.

Local WLAN Connect ivity
Local WLAN Connect ivity

Standa WPS Standard rds

The terminal shall support the WPS (Wi- Easier to connect to a WLAN network N/A Fi Protected Setup) standard for easy and secure establishment of a wireless home network.

Wi-Fi

The terminal should send an

This would improve the time a

N/A

authentication authentication request within 10ms of terminal takes to connect to an AP.

time

identifying a network.

Essential for Wi-Fi Calling (VoWiFi)

Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity
Local WLAN Connect ivity

Wi-Fi Beaconing
Standa Wi-Fi 802.11v rds
Standa Wi-Fi 802.11w rds
Securi WPA3 ty

The terminal scans once on UE

This would enable us to

N/A

activation from standby then after

control/reduce the noise floor of

every minute, while device is active. Wi- 2.4GHz and 5GHz.

Fi beaconing to be completely off

during standby, unless UE connected

to Wi-Fi. (unless user intervenes)

The device shall comply with the IEEE 802.11v ­ Wireless Network

N/A

802.11v standard.

Management ­ Among other

features, it works closely with

802.11k and 802.11r for Fast BSS

Transitions - moving the client to a

different AP within the network in a

seamless way.

The device shall comply with the IEEE 802.11w ­ Protected Management N/A

802.11w standard.

Frames ­ is used to achieve a level of

protection regarding wireless

network management frames in

order to avoid forgery and

subsequent attacks on the wireless

medium.

The device shall support WPA3.

WPA3 provides several security

N/A

improvements over WPA2.

Location A-GPS Based Configuration Service

SUPL Server setting s

SUPL Server configuration

Location A-GPS Based Configuration Service
Location GPS Based Requirements Service

SUPL Server setting s

SUPL V1.0

AGPS

AGPS performance criteria

The SUPL-server address shall be configured in accordance with the Vodafone Variant Settings (VVS). For Vodafone OpCos the address will be: supl.vodafone.com, Port 7275 following SUPL standard unless otherwise specified in the VVS. The device shall support as a minimum SUPL v1.0.

Essential to use Vodafone's SUPL servers
Essential to use Vodafone's SUPL servers. Ideally SUPL 2.0 shall be supported also.

The integrated GPS receiver must conform to the relevant performance requirements defined in 3GPP TS 25.171.

The GPS receiver's performance cannot be guaranteed. This could lead to degraded performance, i.e. a longer Time to First Fix (TTFF), less accurate positioning etc.

N/A
N/A 3GPP TS 25.171

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Location GPS Based Requirements Service
Location Security Based Requirements Service
Location Security Based Requirements Service
Location Security Based Requirements Service

GPS Autonomous GPS support

chipse Access to t level location access information

chipse Access to SMS t level APIs access

Privac y

API for location information

The terminal shall support the Autonomous GPS mode of operation.
The device chipset must be allowed to access and request a full GPS location and/or A-GPS location and/or any location information provided by the location services APIs of the device OS during an emergency call.
The device chipset must be allowed to send a binary SMS during an emergency call (not after the call has ended).
Execution environments that provide APIs for applications to access location information, including (A)GPS and CellID information, must control access to those APIs by applications through the implementation of an appropriate security framework. The security framework should use install and/or runtime notification/confirmation to make the user aware that the application is accessing location information.

If the terminal supports GPS it must N/A

support the Autonomous GPS mode

of operation to allow GPS to be used

when assistance data is not available,

e.g. due to lack of network coverage

or incorrect configuration. Note that

any implementation of GPS that does

not support the Autonomous GPS

mode of operation as a fallback for

Assisted GPS should be questioned

as it is not a sensible

implementation.

This is required as part of the AML

N/A

(advanced Mobile location) service

launched in the UK (currently only

applicable for Android, but

potentially valid for other platform

for the future).

This is only relevant to any device

that can make emergency calls and

which has a location services

capabilities.

This is required as part of the AML

N/A

(advanced Mobile location) service

launched in the UK (currently only

applicable for Android, but

potentially valid for other platform

for the future).

The device must be able to send the

SMS with the location info to the ECC

number.

Uncontrolled access to location

N/A

information by applications is likely

to result in the user's privacy being

compromised. This could have

serious legal and public relation

implications for Vodafone. The use of

a security framework not only

protects the user but enables

different requirements (i.e.

notification and confirmation) to be

imposed on different applications

when accessing location information.

Location Security Based Requirements Service

User Privac y

Global (A)GPS On/Off switch

It must not be possible for an

application to access location

information without using one of the

APIs provided by the execution

environment.

The user shall be able to enable and The user may not want their location N/A

disable (A)GPS through a simple user revealed at specific times or when

interface. The setting shall be applied they are in specific locations. Unless

globally, i.e. across all applications.

a global on/off switch is provided the

Note that in addition to this global

user will not be able to

control, execution environments are enable/disable mobile based

expected to provide their own controls positioning without changing the

that allow users to enable or disable settings for each individual

mobile originating location requests on application (which in turn would

a per application basis (see TCD-LBS_- require the user to remember which

REQ-001270). The UI can be on the

applications had access to location).

device itself, or via a suitable

connected device such as a laptop. The The functionality is limited to (A)GPS

laptop may display a UI generated

as providing control over other

using an exposed device API or by any positioning methods is extremely

other mechanism such as an on device complicated both to implement and

web server.

to explain to the user. In addition,

(A)GPS allows for a much more

accurate location fix.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Location User Plane Based positioning Service
Location User Plane Based positioning Service
Location User Plane Based positioning Service
Location User Plane Based positioning Service
Location User Plane Based positioning Service
Location User Plane Based positioning Service

Concu rrent locatio n reques ts

Support for concurrent User Plane location requests

Defaul t setting s

H-SLP Address Settings

If the terminal supports SUPL 1.0 it must support concurrent location requests
The terminal shall store and determine the H-SLP address in accordance with section 6.2 of OMA SUPL 2.0. Specifically the terminal shall first attempt to read the H-SLP address from the UICC (USIM/SIM). If no H-SLP address is stored on the UICC the terminal shall check if the H-SLP address is stored in the terminal. If no H-SLP address is found in the UICC or terminal, then the terminal shall configure a default H-SLP address based on the IMSI as described in OMA SUPL 2.0.

Concurrent location requests could occur either because multiple applications are making location requests at the same time or because a single application requests a coarse and fine grained location at the same time (to get a rough location before a GPS position is available). Inability to support concurrent requests will lead to a significantly worse user experience in either of the above cases. If the H-SLP address is not stored in a secure location it could be modified by a malicious application. This could compromise the user's privacy and deny access to the AGPS server / location services.

N/A
OMA SUPL 2.0 TS

Support for the different methods for provisioning the H-SLP address is required to ensure that it is possible to automatically re-configure terminals if the address of Vodafone's H-SLP changes. It will also help customise vanilla terminals.

Positio ning schem es
Positio ning schem es
Positio ning techn ologie s

User Plane support for Terminal Initiated Area Event Triggered Services User Plane support for Terminal Initiated Immediate location requests Support Cell ID positioning

The storage of the H-SLP on the terminal must be secure. The terminal should support Terminal (SET) Initiated, area event triggered services as defined in SUPL 2.0
The terminal shall support Terminal (SET) Initiated, Immediate location requests as defined in SUPL 1.0
The terminal shall support the E-CID (Cell ID) positioning calculation function, as defined in OMA SUPL 1.0

Positio ning techn ologie s

Support WLAN positioning

If the terminal supports WiFi, the terminal should support the use WLAN Access Points as Network Measurement information, as defined in OMA SUPL 2.0. Specifically, the terminal should support the use of WLAN AP Info parameter.

Vodafone expects SUPL 2.0 support OMA on the server side in the near future, SUPL 2.0 therefore device support is expected. TS

Non-compliance will mean that services that use Terminal Initiated Immediate location requests will not work with this terminal. This is the main positioning scheme used by location based services clients and must be supported. Cell-ID positioning is used to give a quick, coarse location. As such CellID positioning may be used to give a rough location 1.) before a more accurate (A)GPS position can be established or 2.) in situations where (A)GPS information is not available (i.e. indoors) or 3.) where a rough location is good enough. Failure to support SUPL 1.0 Enhanced Cell-ID positioning will mean that applications on the terminal will not be able to take advantage of Vodafone's SUPL server and Cell-ID database, which will in turn lead to a significantly worse user experience in many applications. Vodafone expects SUPL 2.0 support on the server side in the near future, therefore device support is expected.

OMA SUPL 1.0 ERELD
OMA SUPL 1.0 ERELD
OMA SUPL 2.0 TS

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Location User Plane Based positioning Service

Positio ning techn ologie s

User plane support for AGPS

Location GPS

GPS

Based Requirements

Service

Galileo

The terminal shall support A-GPS SET based position calculation function defined in OMA SUPL 1.0 The terminal may support the A-GPS SET assisted position calculation function defined in OMA SUPL 1.0
The device shall support the Galileo satellite based location system

Applications on the terminal will not be able to use the AGPS functionality supported by SUPL 1.0 or take advantage of Vodafone's SUPL server. This will result in the terminal falling back to Autonomous GPS, which in turn will lead to significantly longer Time To First Fix (TIFF), and/or result in the terminal falling back to other positioning technologies such as Cell ID. Note that many location based services require the accuracy provided by (A)GPS and therefore other positioning technologies are unlikely to suffice. Important to offer increase accuracy
in GPS location, can be compromised
in lower tier devices

OMA SUPL 1.0 ERELD
Location Based Service

Location GPS

GPS

Based Requirements

Service

Glonass

The devices shall support the Glonass satellite system

Important to offer increase accuracy Location

in GPS location, can be compromised Based

in lower tier devices

Service

Location User Plane Based positioning Service
Location User Plane Based positioning Service
Location User Plane Based positioning Service
Messagi SMS ng

Positio ning schem es

User Plane support for Network Initiated Area Event Triggered Services

Positio ning schem es

User Plane support for Network Initiated Immediate location requests

Positio ning schem es

User Plane support for Network Initiated Periodic location requests

Standa rd config uratio n

settings and configuration

The terminal should support Network Initiated, area event triggered services as defined in SUPL 2.0

Vodafone expects SUPL 2.0 support on the server side in the near future, therefore device support is expected.

Location Based Service

The terminal shall support Network Initiated, Immediate location requests as defined in SUPL 1.0 / 2.0
The terminal shall support Network Initiated, Periodic location requests as defined in SUPL 2.0

Non-compliance will mean that services that use Network Initiated Immediate location requests will not work with this terminal. Network Initiated services include services such as track and trace, friend finder etc.

Location Based Service

Non-compliance will mean that services that use Network Initiated periodic location requests will not work with this terminal. Services that may use this service include route trackers, track and trace etc.

Location Based Service

This functionality was only introduced in SUPL 2.0 and therefore may not be widely supported. The same functionality can be achieved (but less efficiently) using multiple Immediate location requests.

Terminal shall support the country

Essential for interworking

VVS

specific settings for the service

configuration and correct operation on

Vodafone network.

Afore mentioned settings can be

access using the latest version of VVS

(Vodafone Variant Setting repository)

(note: in case you do not have access,

please request it to your Vodafone

counterpart)

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Messagi RCS ng
Messagi SMS ng

Standa rd refere nce

Standard compliancy

Gener al Requir ement s

Extended 3GPP character set

In case some settings cannot be supported or configured country per country: please state all limitations in the comment section
Terminal shall support RCS according GSMA specification. In case of non or partial compliance, please state the known limitations in the comment sections. "The terminal shall fully support the input, transmission and display of the extended character sets according to 3GPP TS23.038, including: UCS2 (unicode), GSM7-bit (simple) GSM7-bit (extended) encoding with National Language Single Shift and Shift Locking Mechanism. reference 3GPP TS 23.040 and 23.038

Essential for Vodafone business Impact for interoperability.

Please note, that 2 input modes are required to be supported to ensure good experience and avoid over charging the customer in Vodafone territories:

a) Mode 1: Automatic (default for all languages):
-Use GSM 7 bit encoding as long as simple characters are typed.
- When user attempts to type a nonsimple character (not in GSM 7 bit table):
1. Change encoding into GSM 7 bit extended: single shift or shift lock
2. Change encoding to unicode (16 bit encoding) if it doesn't match above 3 tables. (note, for good UX: if the user deletes the character, the encoding should revert to simple)

a) Mode 2 : restriction to simple characters (default for Portuguese, Spanish and Greek languages)
-Use GSM 7 bit encoding as long as simple characters are typed.
-When user attempts to type a nonsimple character (not in GSM 7 bit table):
1. Change encoding into GSM 7 bit extended: single shift or shift lock
2. Doesn't allow however the input of characters outside the 3 above tables (whatever the method used)
-Prevent the user typing those characters (hide in the keyboard used)
-Pop up giving option to user to switch to Unicode with warning in less characters available in each SMS
3. Change into closest matches (ó into o, û into u, etc...)

Finally, Vodafone requires : -That an option is given in setting to
allow the customers to edit default mode.
-That mode 2: Automatic is set as default for ALL languages with the exception of Spanish, Portuguese and

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

characte rs: -3GPP TS 23.040 -3GPP TS 23.038 Conversi on: -3GPP TS 27.005

Vodafone Group Products & Service

Messagi SMS ng
Messagi SMS ng Messagi MMS ng
Messagi E-mail ng
Messagi RCS ng

Gener al Requir ement s
Gener al Requir ement s Gener al Requir ement s
Gener al Requir ement s
Batter y Consu mptio n

Type 0 support
Independent operation
OMA MMS 1.2 support
Email configuration and Vodafone mail
Minimize impact of RCS/Message + native or preembedded client solution implementatio n on battery consumption

Greek , where Mode 1 : restriction to simple characters should be default. (note: instead of tying the mode to the language, OEM may also decide to configure it according country in use, in which case Mode 1 should be default for Spain, Portugal and Greece and Mode 2 for all other countries.) The terminal shall support the receipt of Type 0 (silent SMS) Short Messages according to the requirements described in 3GPP TS23.040. I.e. the successful delivery shall be acknowledged to the network, but no indication to the user shall be given. Terminal should support Short Message Service-Cell Broadcast. (SMSCB) and correctly display them.
The terminal client shall comply with the OMA MMS specification suite version 1.2
Terminal should first offer the possibility for users to use an email service (create an account, log in to existing account, use emails, delete their accounts) and support popular email protocoles (pop3, IMAP, exchange...). In addition, terminal should support easy configuration by preloading server settings from Vodafone Mail for supported countries. [Also refer to VVS for pre-configured email per market] N shall not be higher than 12 with:
N = Average RCS in idle power consumption in mW multiplied with 8760h devided by the standard device battery capacity in mWh.
To determine the average RCS in idle power consumption, compare energy consumption of: (A) Device with exchange active sync and OS-specific sync (e.g. Google or Live or BlackBerry account) active, ~1500 contacts with MSISDN in address book, screen off, Always-On-Display configured to off, device connected to data, device not moving, RCS off. and (B) same as A but RCS on, and initial contacts discovery finished.

Impact for network connection.
Essential for interworking
Impact for network connection.
CP: MMS Core suggests a move towards MMS 1.3 Without the setting the user will not be able to use Vodafone Mail. May result in additional calls to Customer Care
With N=12: - The RCS in idle additional power consumption in one year (8760h) will be equivalent to 12 times the power contained in a fully charged device battery. - A user draining the battery from full to empty within 24 hours without RCS, would drain the battery within 23:14 hours with RCS in idle. - A user draining the battery from full to empty within 5 days without RCS, would drain the battery within 4 days and 7 hours with RCS in idle. - A user draining the battery from full to empty within X hours without RCS, would drain the battery within 1/(1/730+1/X) hours with RCS in idle. - A user draining the battery from full to R% within H hours without RCS, would drain the battery to (RH/7,3)% after H hours with RCS in idle. Remark: Negative results indicate battery at 0% before H hours - This will happen in case R < H/7,3

3GPP TS 23.040

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Messagi RCS ng
Messagi RCS ng Messagi RCS ng
Messagi RCS ng
Messagi RCS ng
Messagi MaaP ng
Messagi Dual SIM ng

Batter y Consu mptio n
Stack Enable ment
File Transf er

Minimize impact of RCS/Message + native or preembedded client solution implementatio n on battery consumption
RCS only active with unlocked SIM
RCS file transfer file name length limitation

The average RCS in idle power consumption shall not be higher than 9 mW.
To determine the average RCS in idle power consumption, use method described in TCD-RCS_-REQ-012147
An RCS configuration shall only be active (provisioning xml usable, identity registered) while the related SIM is in the device and unlocked (SIM-PIN entered and valid or SIM doesn't require PIN). The file name submitted for file transfer shall be 250 bytes long maximum within the respective encoding.

An analysis of CTC measurements in 2016 has shown the majority of devices is able consuming less than 9 mW average for RCS (in idle).
Devices shall fulfil this requirement to offer best possible user experience / lowest possible battery consumption compared with state of the art / technical feasibility. The user identity is bound to the SIM, not to the device. When the user removes the SIM or when the SIM is not (yet) unlocked, it shall not be possible using the identity for communicating. Very long file names currently cannot be handled by Vodafone servers so file transfer will fail.

Client integr ation
Client integr ation
Messa ging as a platfor m
RCS

Android Messages
Google Carrier Services APK
Maap compliance
RCS support for all SIMs' identities

If the user tries submitting files with longer names (e.g. with special characters consuming several bytes each), the name shall be shortened automatically. Pre-embed Google's Android Messages as the default SMS/MMS/RCS messaging application, with placement in the Hot Seat for all Android Compatible Devices. The latest commercial version should be sourced from Google, and follow Google's integration guidelines. Support on Vodafone customised and Open Market devices is requested. OEM will need to make their own commercial arrangements with Google. Pre-embed Google's Carrier Services APK which is required to support RCS, ensuring that RCS is excluded from power and data saver according to Google's integration guidelines. OEM will need to make their own commercial arrangements with Google. Terminal supplier shall indicate if device supports following functions: Messaging as a platform In case of support, Vodafone requires compliance with industry established standards to ensure the correct operation on Vodafone networks. Following standards shall be observed: GSMA RCS UP latest published version at the time TCD feedback is provided. In case of non or partial compliance, please state the known limitations in the comment sections. The device shall support RCS simultaneously with all SIM identities enabled in the device.

Required to support Vodafone's RCS penetration ambition
CS.APK is an essential component for Google RCS support to Android Messages and Google Phone applications. Without exclusion from power saving, the user won't be reachable via RCS after the device was in idle on battery for a long time without significant movement restriction in A2P revenue
Necessary for reliable continuous RCS service availability for the user and reachability for his contacts.

Messagi Dual SIM ng

RCS SIM identity selection in messaging

If the user has made the choice sending a message with a specific SIM/identity, this shall be valid for SMS, MMS and RCS at the same time.

If requirement is not fulfilled, contacts might get confused by getting messages from an unknown MSISDN and by getting messages from the same person within

GMSA had specified different ly

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Messagi Dual SIM ng
Messagi Dual SIM ng Messagi Dual SIM ng
Messagi Dual SIM ng
Messagi RCS ng

Same is valid for all communication in the messaging area (chat, group chat, file share, location share, ...)

multiple conversation threads.

E.g.: If the user choses sending a

message from MSISDN A, the device

shall not try sending the message via

RCS from MSISDN B.

RCS SIM selection All RCS user dialogues that might refer

UI

to one of the SIMs only shall clearly

specify to which SIM they are related.

initially. Ensure not impleme nting old GSMA spec.

The means used for differentiating SIMs (i.e. names, icons, colours) shall be consistent across all the device.

Notes:

- In RCS context especially relevant for

RCS-master-switch, provisioning

MSISDN request, RCS related settings if

differentiated between SIMs.

- Avoid confusion between references

to SIMs and to SIM slots.

- Ensure other visuals (e.g. xMS/Chat

differentiation) aren't lost by

introducing Dual SIM indications.

RCS Differentiate During RCS authentication related to a Prevent provisioning fail and prevent

SIMs for

specific SIM RCS identity using One- provisioning with wrong identity.

receiving OTP Time-Password (OTP) via SMS, only

during

SMS messages received with the same

provisioning specific SIM shall be considered for

extracting the OTP.

RCS Using other For RCS identification and

Prevent provisioning fail and prevent

SIM's mobile authentication purposes related to a provisioning with wrong identity.

data channel specific SIM identity (i.e. initial

during

provisioning using network

identification authentication), the mobile data

or

channels of other SIMs shall be

authentication considered same way as a Wi-Fi

network.

RCS Using other SIM's mobile data not related to identification or authentication
Stack 2 Factor Enable Authentificatio ment n provisioning

Example: SIM1 mobile data is active / Wi-Fi off / other SIM = SIM2 is trying to provision with RCS --> The provisioning procedures for Wi-Fi need to be used. In case RCS needs to consider the data bearer for purposes not related to identification or authentication while RCS data is routed via mobile data of the SIM which is not related to the RCS identity, the actual connection mode shall be considered. NOTE: E.g. for RCS video share codec negotiation, the correct connection mode of the mobile data SIM currently in use needs to be considered. Devices should support 2 factor authentification as described in the RCS GSMA specs. Please refer to the latest publish version of the spec (RCC.71) for details. 2 factor authentification means users getting provisioned over any bearer, including where HE is available, they will receive an OTP to ensure the received MSISDN is the real MSISDN in the device - HE + SMS OTP

Correctly consider expected available bandwidth e.g. to avoid drops and bad quality in video share.
Main areas to be improved: * Make HE even more trustable * Avoid hotspot scenarios, where the user getting provisioned 'steal' credentials from the user/device providing wifi

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Messagi CBS ng

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Basic requir ement s

MNPWS Service ­ Cell Broadcast

Device TAC / GSMA registration
Device Operating System Support
Device Network Lock/Unlock

The device with connected display shall support the Mobile Network Public Warning System (MNPWS) based on 3GPP Rel-11 (EU-Alert). The warning messages shall be delivered by Cell Broadcast System via 2G, 3G, 4G and later 5G Network. The messages shall be displayed without user action and with distinct warning tone sounded. The device shall support multiple languages. For OpCo specific cell broadcast channels and settings please refer to Vodafone VVS.
The Vendor shall register a Vodafonebranded Mobile Broadband device with the GSMA. The registration must be inline with the Vodafone template (see MBB reference document). The TAC code shall be uniquely identifiable as a Vodafone device.
The Device shall support the following Operating Systems:

The MNPWS Service is relevant for NL and RO. In addition to GR, ES and IT are planning MNPWS, timeline tbd.
Required for mobile broadband devices
Required for mobile broadband devices

ETSI TR 102 900, ETSI TR 102 850 3GPP TS 22.268 3GPP TS 23.041 Radio interface : 3GPP TS 25.304, 3GPP TS 25.331, 3GPP TS 36.304, 3GPP TS 36.331, 3GPP TS 45.002, 3GPP TS 44.018, Vodafon e VVS Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A

· Windows XP/Vista/7, 8.1 and 10 (32 and 64 Bit)

· Apple Mac OS X 10.5.8 Leopard (Intel/PPC) · Apple Mac OS X 10.6.x Snow Leopard (Intel) · Apple Mac OS X 10.7.x Lion (Intel) · Apple Mac OS X 10.8.x Mountain Lion (Intel) · Apple Mac OS X 10.9.x Mavericks (Intel) · Apple Mac OS X 10.10.x Yosemite (Intel) · Apple Mac OS X 10.11.x El Capitan (Intel)

Wi-Fi Hotspots shall be OS agnostic.

The Device shall support Network Lock Required for mobile broadband

N/A

/ Unlock as specified by 3GPP.

devices

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Device Network Lock/Unlock Tools

The Vendor shall provide development tools that can be used to network lock and unlock the Device. The tools shall support Windows 7 , 8 and 10.

Required for mobile broadband devices Dependency: Network Lock/Unlock

Device

USB 2.0 High Speed, USB 3.0

The tools are also required to validate the Network Lock / Unlock features. The Device shall be compliant with USB 2.0 and maintain backwards compatibility with previous versions as specified by the USBIF.

Required for mobile broadband devices

Device Unique USB VID / PID Combination

All Vodafone-branded MBB devices shall have a unique VID / PID Combination. The device shall expose a unique VID/PID combination both before and after the conversion process.

Required for mobile broadband devices

The VID/PID must be consistent across all interfaces (e.g. RNDIS, MBIM & Update interfaces).

Details on the PID / VID structure are available in the MBB Reference document.

Device

Vodafone Common Update Framework

The Vendor shall support the Vodafone Common Update Framework when providing firmware updates for Vodafone branded devices.

Required for mobile broadband devices

Detailed information is available in the MBB reference document.

Drivers Drivers

No Vendor Name Displayed during Driver Install Open Source Linux Drivers with GPL Licence

IPv6 IPv6 - PDP Contexts

The Device shall not display the Vendor Required for mobile broadband

name to the customer during driver

devices

installation.

The Vendor shall supply GPL open source drivers for all devices.

Required for mobile broadband devices

(1) The Device shall be capable of requesting and supporting a dual address PDP context according to 3GPP TS 24.008 clause 10.5.6.4 R8 (PDP Type value Hex 8D)

Required for mobile broadband devices

(2) The Device shall be capable of supporting two simultaneous primary PDP contexts to the same APN, one with PDP Type IPv4 and one with PDP Type IPv6 as defined in 3GPP TS 23.060 clause 9.2.1

(3) The Device shall be capable of falling back to (2) if (1) results in a single IP address being allocated with SM cause #52 'Single address bearer

N/A
N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Custo m CID / Device Servic es
Custo m CID / Device Servic es
Custo m CID / Device Servic es
Custo m CID / Device Servic es Device

MBIM Device Service - CellID & LAC (AT+CREG)
MBIM Device Service - Hard reset
MBIM Device Service - Soft reset
MBIM Device Service - Write MSISDN to SIM
MBIM Support

only allowed' or if (1) results in a successful PDP Context activation with address IPv4. as defined 3GPP TS 23.060 clause 9.2.1 and 24.008 clause 10.5.6.6 The Device shall support CellID & LAC (AT+CREG) via MBIM Device Services and shall expose an object which includes the following information as per the AT+CREG Command: · CellID · RNCID · LAC The Device shall support "Hard reset" via MBIM Device Services. The desired behaviour is as follows:
· Hard reset triggered · Remove from Device Manager · Re-enumerate and boot from fresh · Delete all NvRAM configuration The Device shall support "Soft reset" via MBIM Device Services. The desired behaviour is as follows:
· Soft reset triggered · Keep device in Device Manager · Reboot the device and re-initialise from Pin "Enter", all the way up the stack The Device shall have the ability to write the MSISDN to the SIM card via MBIM Device Services. This capability shall be accessible via the MBN APIs.
The Device shall comply with the MBIM 1.0 specification and shall support all mandatory MBIM CIDs.

Required for mobile broadband devices Dependency will be on MBIM_CID_DEVICE_SERVICES
Required for mobile broadband devices Dependency will be on MBIM_CID_DEVICE_SERVICES
Required for mobile broadband devices Dependency will be on MBIM_CID_DEVICE_SERVICES
Required for mobile broadband devices Dependency will be on MBIM_CID_DEVICE_SERVICES
Required for mobile broadband devices

Mobile Broadba nd

MBIM

Device Windows 10 MBIM Support

The Device shall support MBIM-Based Mobile Broadband Requirements for Windows 10

Required for mobile broadband devices Dependency: MBIM Support

Mobile Broadba nd

MBIM

Device USBIF Compliance

The Device MBIM Interface must pass the USBIF compliance program.

Required for mobile broadband devices Dependency: MBIM Support

Mobile Broadba nd

MBIM

Device

Windows Hardware Certification Program

The Device shall comply with the Windows Hardware Certification (WHC) Program for Mobile Broadband.

Required for mobile broadband devices

For Vodafone Branded Devices, the following values should be used for the Logo submission:

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

N/A
N/A
N/A
N/A
http://w ww.usb. org/dev elopers/ devclass _docs/M BIM10.zi p http://m sdn.micr osoft.co m/enus/wind ows/har dware/h h91860 0 http://w ww.usb. org/dev elopers/ complia nce/ http://m sdn.micr osoft.co m/enus/librar y/windo ws/desk top/br2 30808.a

Vodafone Group Products & Service

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Device

WHC Certificate Transfer to Vodafone

Device Identity Morphing

Product name: Vodafone <model name>

Marketing name: Leave Blank

Device metadata category: Network > Mobile Broadband Network The Vendor shall transfer the WHC Certificate to "Vodafone Group Service" via WHDC.

Required for mobile broadband devices

Vodafone require the following items before Technical Acceptance can be granted: · A copy of the passed WQReady.xml file generated by the Logo Test Kit · An email containing the Submission ID The Device shall support "Identity Morphing" as specified by Microsoft to allow different USB interfaces to be exposed on different operating systems.

Required for mobile broadband devices

Details on the USB interface specification can be found in the MBB reference document.

Mobile Broadba nd

MBIM

Device

MBIM USB Device naming for Vodafone Branded Devices

The Vendor shall comply the Vodafone specification for MBIM USB Device naming.
The definition shall be found in the MMB Reference document.

Required for mobile broadband devices

This requirement is only applicable to Vodafone Branded Devices.

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Device Network Unlock via MBIM CID

The Vendor shall map the SIM lock OID to the following OID: MBN_PIN_TYPE_NETWORK_PIN

Required for mobile broadband devices

This is PH-NET PIN from 3gpp TS27007

Generi MBIM_CID_ST c CID K_PAC

The Vodafone VMBAE will provide a UI to perform network unlock on Windows 10 This CID is used to propagate proactive commands from the SIM card to the host. A proactive command is always triggered from the SIM card.

spx
N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile MBIM

Generi MBIM_CID_ST This CID is used to send a Device

N/A

Broadba

c CID K_Device_RES response to a proactive command.

nd

PONSE

Mobile MBIM

Generi MBIM_CID_ST This CID is used to send an envelope

N/A

Broadba

c CID K_ENVELOPE command from the host to the SIM

nd

card.

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Generi MBIM_CID_AK This CID is used to send an

Required for mobile broadband

N/A

c CID AP_AUTH

authentication challenge to the device. devices

The device must use the AKA 3rd

generation Authentication and Key

Agreement mechanism, specified for

Universal Mobile Telecommunications

System (UMTS) in [TS33.102].

Generi MBIM_CID_SI This CID is used to send an

Required for mobile broadband

N/A

c CID M_AUTH

authentication challenge to the device. devices

The device must use the

authentication mechanism that is

based on the GSM authentication and

key agreement primitives which is a

2nd generation mobile network

standard.

Generi MBIM_CID_AK This CID is used to send an

Required for mobile broadband

N/A

c CID A_AUTH

authentication challenge to the device. devices

The device must use the AKA 3rd

generation Authentication and Key

Agreement mechanism, specified for

Universal Mobile Telecommunications

System (UMTS) in [TS33.102].

Generi MBIM_CID_SE This command instructs devices to

N/A

c CID RVICE_ACTIVA initiate service activation in order to

TION

gain access to the provider's network.

Mobile MBIM

Generi MBIM_CID_PH This CID is used to retrieve information

N/A

Broadba

c CID ONEBOOK_CO of the device phonebook.

nd

NFIGURATION

Mobile MBIM

Generi MBIM_CID_PH This CID is used to read one or all

N/A

Broadba

c CID ONEBOOK_RE entries from the device phonebook.

nd

AD

Mobile MBIM

Generi MBIM_CID_PH This CID is used to delete one or all

N/A

Broadba

c CID ONEBOOK_DE entries in the device phonebook.

nd

LETE

Mobile MBIM

Generi MBIM_CID_PH This CID is used to write an entry to the

N/A

Broadba

c CID ONEBOOK_WR device phonebook.

nd

ITE

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Generi MBIM_CID_DE The function prepares and returns an Required for mobile broadband

N/A

c CID VICE_CAPS

MBIM_DEVICE_CAPS_INFO structure in devices

response to a

MBIM_COMMAND_MSG with

UUID_BASIC_CONNECT and CID

MBIM_CID_DEVICE_CAPS.

Generi MBIM_CID_PA This command is used to instruct

Required for mobile broadband

N/A

c CID CKET_SERVICE devices to perform packet service

devices

attach or detach actions on the current

registered provider's network for

GSM-based. In addition to the packet

service attach/detach status, this CID is

used to determine data class

availability, the currently used data

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

class information, and the uplink and downlink speeds.

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Generi MBIM_CID_CO This command activates or deactivates Required for mobile broadband

N/A

c CID NNECT

a particular IP data stream session and devices

reads the activation state of a session.

Generi MBIM_CID_PR This command reads or updates the

N/A

c CID OVISIONED_C provisioned context entries stored on

ONTEXTS

the MB device or the Subscriber

Identity Module (SIM).

Generi MBIM_CID_IP_ Sometimes, some or all of the IP

Required for mobile broadband

N/A

c CID CONFIGURATI configuration information is obtained devices

ON

as part of the procedure in which the

link-layer for data services is

established. In such cases, the MBIM

function acquires IP configuration

information from the carrier network

on behalf of the host. This CID is used

to transfer such IP

configuration information from an

MBIM function to the host.

Generi MBIM_CID_PA This command returns the packet

N/A

c CID CKET_STATIST statistics for all the Raw IP Data

ICS

Streams kept by the device. These are

IP packet statistics, unrelated to the

underlying NTB transport used to

transfer the IP packets.

Generi MBIM_CID_IP_ This command returns information

N/A

c CID PACKET_FILTE about the list of packet filters and

R

allows that list to be set. These packet

filters apply exclusively to IP data

stream sessions.

Generi MBIM_CID_RA The command sets or returns

Required for mobile broadband

N/A

c CID DIO_STATE

information about a MB device's radio devices

power state.

Generi MBIM_CID_HO This command sets or returns

Required for mobile broadband

N/A

c CID ME_PROVIDER information about the home provider devices

of the cellular service subscription. For

GSM-based devices and CDMA-based

device with U-RIM, this information

should be stored on the Subscriber

Identity Module (SIM card).

Generi MBIM_CID_PR This command returns information

N/A

c CID EFERRED_PRO about the list of preferred providers for

VIDERS

GSM-based devices.

Generi MBIM_CID_VIS This command returns a list of network Required for mobile broadband

N/A

c CID IBLE_PROVIDE providers currently visible within the devices

RS

MB device's range.

Generi MBIM_CID_RE This command selects a network

Required for mobile broadband

N/A

c CID GISTER_STATE provider with which to register. MBIM devices

supports two registration methods:

automatic and manual.

Generi MBIM_CID_SIG This command returns or sets the

Required for mobile broadband

N/A

c CID NAL_STATE current signal state.

devices

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Generi MBIM_CID_MU This command returns a list of network

N/A

c CID LTICARRIER_P providers that are the preferred

ROVIDERS

providers for a multi-carrier function.

The CID is supported when the device

reports support for

MBIM_CTRL_CAPS__MULTI_CARRIER.

Generi MBIM_CID_SU The function prepares and returns an Required for mobile broadband

N/A

c CID BSCRIBER_RE MBIM_SUBSCRIBER_READY_INFO

devices

ADY_STATUS structure in response to an

MBIM_COMMAND_MSG with

UUID_BASIC_CONNECT and

MBIM_CID_SUBSCRIBER_READY_STAT

US. This structure contains the

Subscriber Identity Module (SIM) card

ready state as well as some information

on the SIM card (SubscriberId, IccId,

Telephone numbers).

Generi MBIM_CID_PIN During the initialization process, the Required for mobile broadband

N/A

c CID

host does not proceed to registration devices

until PIN1 is successfully unlocked, if

enabled. The host provides a PIN value,

entered by the end user, in the Pin

member of the MBIM_SET_PIN

structure when processing set

requests. The function must process

the request only when the PIN value

matches the value stored in the SIM

card. Otherwise, functions must fail the

set request with status code

MBIM_STATUS_FAILURE.

Generi MBIM_CID_PIN This command returns a list of all the Required for mobile broadband

N/A

c CID _LIST

different types of Personal

devices

Identification Numbers (PINs) that are

supported by the MB device and

additional details for each PIN type,

such as the length of the PIN

(minimum and maximum lengths), PIN

format, PIN-entry mode

(enabled/disabled/not-available). This

CID also specifies the current mode of

each PIN supported by the function.

Generi MBIM_CID_EM This CID returns information about an

N/A

c CID ERGENCY_MO MBIM function's emergency mode

DE

state. This CID applies to functions that

are capable of supporting emergency

mode. Emergency mode could be over

the traditional voice or over VoIP.

Generi MBIM_CID_US This CID is used to control the

Required for mobile broadband

N/A

c CID SD

Unstructured Supplementary Service devices

Data (USSD) according to 3GPP TS

22.090 [3GPP22090].

Generi MBIM_CID_SM This command indicates the state of Required for mobile broadband

N/A

c CID S_CONFIGURA the SMS storage and also sets or

devices

TION

returns a MB device's SMS text

message configuration.

Generi MBIM_CID_SM This command reads SMS text

Required for mobile broadband

N/A

c CID S_READ

messages stored in the MB device, or devices

Subscriber Identity Module (SIM card),

or any other auxiliary non-volatile

memory or memories.

Generi MBIM_CID_SM This command sends SMS text

Required for mobile broadband

N/A

c CID S_SEND

messages to another device capable of devices

receiving SMS.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Generi c CID
Generi c CID

MBIM_CID_SM S_DELETE
MBIM_CID_SM S_MESSAGE_S TORE_STATUS

This command deletes SMS text messages stored in the MB device, or Subscriber Identity Module (SIM card), or any other auxiliary non-volatile memory or memories. This command reports the status of the MB device's message store.

Required for mobile broadband devices
Required for mobile broadband devices

Mobile Broadba nd

MBIM

Generi c CID

MBIM_CID_DE VICE_SERVICE S

This CID is used to query the device services supported by the MBIM devices and their properties.

Required for mobile broadband devices

Mobile Broadba nd

MBIM

Mobile Broadba nd

MBIM

Generi c CID
Generi c CID

MBIM_CID_DE VICE_SERVICE _SUBSCRIBE_L I
MBIM_CID_DS S_CONNECT

The host uses this CID to inform the function of the CIDs for which the host wishes to receive unsolicited events via MBIM_INDICATE_STATUS_MESSAGE. As a result, the function must only indicate notifications for CIDs which have been enabled via this CID. The host updates this list appropriately as its state changes. State changes at the host are possibly triggered by events received from the function (including "wake up" from dormant states). Upon re-enabling suppressed notifications the host is responsible for synchronizing to the latest device state by performing queries for those CIDs.
This CID activates and deactivates a data stream channel over the bulk pipe for a non-IP based Device Service.

Required for mobile broadband devices
Required for mobile broadband devices

Mobile Broadba nd

MBIM

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Generi c CID
Device

MBIM_CID_NE TWORK_IDLE_ HINT
UPNP Support

This CID is a network idle mode hint from the host to the function. The MBIM function can use this hint in its heuristics to enable mechanisms such as `Fast Dormancy', and to faster enter low power modes in its network operations. The tradeoff, of course, is potentially longer latency. The host also uses its own heuristics to determine when to send this hint to the function, and may typically happen when the host estimates that for a period of time there will be a reduction in network traffic via this MBIM function, or if the host is entering some idle state. The Device shall support UPNP. Must be disabled for Mobile WiFi by default with possibility to turn on in Web Interface.

Required for mobile broadband devices

Device

UPNP Support for SD Card File Access via WLAN

The Device shall support SD Card file access via WLAN using UPNP.

Required for mobile broadband devices

Windo ws 10

Network Cost Information exposed via WiFi Beacon

The Device shall provide Network Cost Information Element via WiFi Beacon.

Required for mobile broadband devices

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

N/A N/A N/A N/A
N/A N/A
N/A N/A http://m sdn.micr osoft.co m/enus/librar y/windo ws/hard

Vodafone Group Products & Service

Mobile Broadba nd

Mobile Wi-Fi

Windo PnP-X Support The Device shall support the PnP-X

ws 10

protocol as specified by Microsoft.

Required for mobile broadband devices

Mobile Broadba nd

Mobile Wi-Fi

Windo ws 10

Vodafone Branded PnP-X Elements

The Vendor shall ensure that all PnP-X Elements are Vodafone Branded. The Vendor name shall not be visible to the user.

Required for mobile broadband devices

Mobile Broadba nd

QuickStart

Mobile Broadba nd

QuickStart

Mobile Broadba nd

QuickStart

Device Firmware Size & AutoRun volume
Drivers ECM Driver for Apple Mac

For a USB Modem which requires an Autorun volume. A minimum of 128MB of available memory should be provided with at least 90MB of it available for Vodafone Mobile Broadband dashboards and additional value added software. The Vendor shall provide an ECM Driver for Apple Mac.

Required for mobile broadband devices
Required for mobile broadband devices

Drivers

Vodafone Branded Windows Drivers for Firmware Update

The Vendor shall provide Vodafone Branded Windows drivers for firmware update.

Required for mobile broadband devices

ware/hh 770509
MBB Referen ce docume nt · PnPXhttp: //msdn. microsof t.com/e nus/wind ows/har dware/g g46308 2.aspx/  · Windows Rally(htt p://msd n.micros oft.com/ enus/wind ows/har dware/g g46301 8.aspx/ ) Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

Generic

Mobile Broadba nd

Generic

Mobile Broadba nd

MBIM

Device Device Device

Apple Mac Ethernet Emulation (RNDIS Style)
Linux Ethernet Emulation (RNDIS Style)
Bearer Type MBIM

The Vendor shall provide Ethernet style device drivers which support high speed data transfer (100mbs+). These drivers shall work on all required versions of MAC OS in both x32 & x64 architecture. The Linux driver for Vodafone-branded MBB shall expose the device as an Ethernet interface (CDC_Ether) or provide kernel extensions allowing the device to support high speed data throughput (100mbs +). The Vendor shall implement the Vodafone definition of the MBIMDATACLASSCUSTOM for all MBIM devices.

Required for mobile broadband devices
Required for mobile broadband devices
Required for mobile broadband devices

The definition shall be found in the MMB Reference document.

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Certifi cation
Certifi cation
Certifi cation

USBIF Compliance for Mobile WiFi Devices
Windows Hardware Certification Windows logo program for Routers Wi-Fi Alliance Certification

The Device shall be certified by the USBIF Compliance Program.

Required for mobile broadband devices

The Device shall be certified by the Windows Hardware Certification Program and be compliant with all mandatory requirements for routers.

Required for mobile broadband devices

The Device shall by certified by the WiFi Required for mobile broadband

Alliance.

devices

Device Auto APN configuration

The Device shall automatically connect Required for mobile broadband to the internet once it receives power. devices
· The Device shall store a table with APNs for all Vodafone Operators in the device firmware · The Device will automatically try and connect to each APN in the order defined in the lookup table · Once the device makes a successful connection, the APN profile is set as default and placed in the highest priority in the APN list for future use. · The Device shall provide the ability to manually select an APN in the WebUI · If a custom APN profile is created in the WebUI, this is set as the default profile for future use
Further details on the APN database and connection logic can be found on the Microsoft web site.

N/A
N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
N/A
N/A
Further informat ion is publicly available on the Microsof t web site

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Device RNDIS Utility

The Vendor shall provide a "Convert to Required for mobile broadband

RNDIS" utility.

devices

Device

Custom Vodafone SSID

This tool shall support all devices (e.g. Routers and USB sticks) currently supplied by the Vendor to Vodafone. The Vendor shall implement SKU aware Vodafone SSIDs.

Required for mobile broadband devices

Further details are available in the MBB reference document.

Mobile Broadba nd

Mobile Wi-Fi

Device

Device Connectivity Behaviour Initial Power On

- Initial Power On when on Automatic Modem

Required for mobile broadband devices

The Device shall automatically connect to a network when switched on and configured in "Automatic modem" mode. The Device shall enter a power saving mode if no devices are attached via WiFi. The Device shall switch off WiFi after 10 minute and 3G after 60 minutes. The user will be required to press a button on the device (power button) to wake up the device. When the charger is connected to the device, 3G and WIFI should always remain switched on.

N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A

- Initial Power On when on Manual Modem via WiFi

The Device shall require user input to

connect to the network when

configured in "Manual modem" mode.

This can be accomplished via the Web

UI.

Mobile Mobile Wi-Fi Device Device

Powered by Battery

Required for mobile broadband

N/A

Broadba

Connectivity

devices

nd

Behaviour -

The Device shall disconnect from the

Monitoring

3G network and enter sleep mode

associated

when powered by battery and no users

devices

are connected to WiFi for a period of 10

minutes.

Powered by USB Cable or via Mains Power
The Device shall not enter Sleep mode when powered by USB Cable or Mains Power. If the device was previously in sleep mode (e.g. if previously powered by battery), the Device shall automatically establish a WiFi connection and connect to the 3G

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

network when in "Automatic mode". In "Manual mode" the device shall only establish a WiFi connection but shall not connect to a 3G network.

Mobile Broadba nd

Mobile Wi-Fi

Device Product naming

On Demand Mode

The Device shall support an "On demand mode" where use of the 3G backhaul should only be on a "On demand" basis. The Vendor shall use the Vodafone product name instead of the Vendor's generic product name. The product name must be used in a consistent way. The Vendor shall implement the Vodafone- branded model for all of the possible elements which are exposed via the device.

Required for mobile broadband devices

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Device DNLA Media Server

The Device shall preinstall a licensed copy of the TwonkyMedia Server software from PacketVideo.

Required for mobile broadband devices

Device

Linux Operating Systems Enviroment

Device Linux Tool Chain & Compliers

Device No Throughput Limitation
Device Non Plug-andPlay Variant

Device Required RAM

TwonkyMedia server can be used to share and stream media to most UPnP AV or DLNA-compliant clients, in addition to non-UPnP devices through the HTML, RSS, and JSON supported front-ends. The Device shall support Linux development environment.

Required for mobile broadband devices

The Vendor shall provide the Linux Tool Chain and Compliers to allow Vodafone to develop Linux binaries and components that run on the Mobile WiFI hardware. The Device shall expose the maximum uplink and downlink of the baseband chipset to the client that is connected to the device via WiFi & USB.

Required for mobile broadband devices
Required for mobile broadband devices

The Device shall only expose Network Adapters when operating in a non plugand-play mode. The CD-ROM or SD Card shall not be exposed. The Device shall behave / assume that the software and drivers are already preinstalled. The Device shall provide a minimum of 512MB RAM. 1GB is preferred.

Required for mobile broadband devices
Required for mobile broadband devices

Mobile Broadba nd

Mobile Wi-Fi

Device SD Card Support

The Device shall support SD Cards.

Required for mobile broadband devices

Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
N/A
N/A
N/A
N/A
N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Device SIM / Product The Device shall support multiple

SKU

SKUs.

Device USB Requirements

NVRAM parameters shall be used to denote the SKU. The SKU will be determined during the factory provisioning process and will identify the end Vodafone target. The Device shall expose Vodafone defined USB interfaces based on the OS.

Details can be found in the MBB reference document.

Required for mobile broadband devices
Required for mobile broadband devices

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

Displa Network

y

Names

The Device shall display the network name based on the VF operator SIM Card. The Device shall display the LONG network name. (e.g. "Vodafone.de" should be shown when a VF Germany SIM is detected and the customer is registered on the Vodafone Germany network. If a VF Germany customer is roaming in the UK, the bearer should be 3G|HSDPA while the network name should match the PLMN that the user is on eg 23415 = "Vodafone UK")

Required for mobile broadband devices

The Vendor shall display the default device name when the network cannot be recognised.

Displa y

Opco Specific Network Bearer Names

Details can be found in the MBB reference document. The Device shall display the bearer name based on the Vodafone Operator SIM card. The bearer name shall be displayed in the connectivity bar and also when showing the "Available Mobile Networks" ­ preferred networks and service when a network scan is performed.

Required for mobile broadband devices

Details can be found in the MBB reference document.

Mobile Broadba nd

Mobile Wi-Fi

Displa Network band

y

preference

The Device shall provide the ability to select Network Band Preferences. The following 3 modes shall be supported.

Required for mobile broadband devices

· 3G Preferred ­ Device will search first and register on 3G Bands with priority ahead of GPRS bands (Default) · 3G Only ­ Device will only search and register on 3G Bands · GPRS Only ­ Device will only search

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A

Vodafone Group Products & Service

Mobile Broadba nd

Mobile Wi-Fi

Displa Display UI

y

Elements

and register on GPRS Bands

For 4G capable devices: · 4G Preferred ­ Device will search first and register on 4G bands with priority ahead of 3G and GPRS bands · 4G Only ­ Device will only search and register on 4G bands

The selected mode shall be retained on device reboot. The Vendor shall support the minimum set of UI Display elements that are needed to support the basic use case.

Required for mobile broadband devices

The Vendor shall implement these elements as defined by Vodafone.

Mobile Mobile Wi-Fi ID Broadba nd

Industrial Design

Details can be found in the MBB reference document.

The Vendor shall adhere to Vodafone Industrial Design guidelines.
Details can be found in the MBB reference document.

Required for mobile broadband devices

Mobile Broadba nd

Mobile Wi-Fi

WebUI Vodafone Mobile Wi-Fi Hardware API

The Device shall support the latest version of the "Vodafone Mobile Wi-Fi Hardware API"
The specification is available in the MBB Reference document.

Required for mobile broadband devices

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

WebUI Default IP and Hostname

The Device shall use the following default IP address: 192.168.0.1 and hostname: http://VodafoneMobile.wifi

Required for mobile broadband devices

WebUI SD Card API access

For VHA Pocket Wi-Fi devices, the Web UI shall be accessible via the following IP address: http://192.168.0.1 and hostname: http://pocket.wifi/ The Device shall support access to the SD Card through Web APIs.

Required for mobile broadband devices

Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd

Mobile Wi-Fi

Mobile Broadba nd

Mobile Wi-Fi

WebUI Concurrent Users

The Device shall support a minimum of 5 concurrent users, configurable on per VF OpCo basis, detected by the SIM. The user shall not be able to change the number of concurrent users.

Required for mobile broadband devices

The maximum number of concurrent users shall be set by the Vendor prior to shipment. Unless otherwise specified by a Vodafone Operator, the default shall be 10 concurrent users.

WebUI DNS Hostname customisation

Should the currently associated users to the hotspot exceed the configured maximum concurrent users then a new user will not be able to locate or associate against the hotspot when performing a network search until the level of concurrent users has dynamically decreased. The Device shall provide the capability for custom DNS Hostnames.

Required for mobile broadband devices

Mobile Broadba nd

QuickStart

Mobile Broadba nd

QuickStart

Device

Auto APN configuration for USB Dongles

Device AutoRun Capability

The Device shall automatically connect Required for mobile broadband to the internet once it receives power. devices

· The Device shall store a table with APNs for all Vodafone Operators in the device firmware · The Device will automatically try and connect to each APN in the order defined in the lookup table · Once the Device makes a successful connection, the APN profile is set as default and placed in the highest priority in the APN list for future use. · The Device shall provide the ability to manually select an APN in the WebUI · If a custom APN profile is created in the WebUI, this is set as the default profile for future use

Further details on the APN database and connection logic can be found in the MBB Reference document. The Device shall support an embedded solution for Plug & Play for installing software and connecting to the internet.

Required for mobile broadband devices

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti

Vodafone Group Products & Service

Mobile Broadba nd

QuickStart

Mobile Broadba nd

QuickStart

Device RNDIS Utility for Quickstart
Device Product naming for Quickstart

The Vendor shall provide a "Convert to Required for mobile broadband

RNDIS" utility.

devices

This tool shall support all devices (e.g. Routers and USB sticks) currently supplied by the Vendor to Vodafone. The Vendor shall use the Vodafone product name instead of the Vendors generic product name. The product name must be used in a consistent way. The Vendor shall implement the Vodafone- branded model for all of the possible elements which are exposed via the device.

Required for mobile broadband devices

Mobile Broadba nd

QuickStart

Device SIM / Product SKU for USB Dongles

The Device shall support multiple SKUs.
NVRAM parameters shall be used to denote the SKU. The SKU will be determined during the factory provisioning process and will identify the end Vodafone target.

Required for mobile broadband devices

Mobile Broadba nd

QuickStart

Device

USB Requirements for USB Dongles

The Device shall expose Vodafone defined USB interfaces based on the OS.
Details can be found in the MBB reference document.

Required for mobile broadband devices

Mobile Broadba nd

QuickStart

Mobile Broadba nd

QuickStart

Device Memory for Vodafone ISO

The Vendor shall reserve a minimum of Required for mobile broadband

90MB of onboard memory on the

devices

Device for a Vodafone ISO.

WebUI Vodafone QuickStart Hardware API

The Device shall support the latest version of the "Vodafone Quickstart Hardware API"
The specification is available in the MBB Reference document.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

ng their Microsof t interface
N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface N/A
Microsof t Partners can obtain the MBB Referen ce

Vodafone Group Products & Service

Mobile Broadba nd

QuickStart

WebUI Default IP and Hostname for USB Dongles

The Device shall use the following default IP address when inserted into a PC: 192.168.9.1. This address has been chosen to ensure that there is no conflict with other "router" products.

Required for mobile broadband devices

Docume nt by contacti ng their Microsof t interface N/A

The default hostname for the device shall be:
- http://vodafonemobile.vmb
- The Vodafone WebUI shall be directly accessible from this URL
- The customer shall be able to change this URL in the WebUI

Mobile Broadba nd

QuickStart

Mobile Broadba nd

QuickStart

The direct access hostname for the device shall be:

- http://vodafonemobile.api

- This hostname is always accessible and not changeable programmatically or via the WebUI

WebUI

SD Card API access for USB Dongles

- This would be used by the VMB SDK for accessing the Hardware API The Device shall support access to the SD Card through Web APIs.

Required for mobile broadband devices

WebUI

DNS Hostname customisation for USB Dongles

The Device shall provide the capability for custom DNS Hostnames.

Required for mobile broadband devices

Mobile Broadba nd

QuickStart

WebUI HTTP WebUI Server

The Device shall include a HTTP Webserver and WebUI for management.

Required for mobile broadband devices

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

N/A
Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by

Vodafone Group Products & Service

Mobile Broadba nd

Generic

Mobile Broadba nd

Feature

Mobile Broadba nd

Feature

Device

Multiple PDP context supported as per MBIM specification

Core Voice, FAX, POS support
Legal Cell ID and LAC

The device shall support multiple PDP context as defined in the MBIM specification and it should pass Windows Hardware Certification Kit (WHCK) tests specific to Multiple PDP Context.

Required for mobile broadband devices running Windows 10.

Device firmware shall support multiple IP data streams as detailed in section 10.5.12.1 in MBIM specification. This includes supporting all the control implementation of CIDs and IP data streams for full support of multiple PDP contexts.

Device firmware shall support a total of 8 dual bearer (IPv4 & IPv6) PDP contexts for usage by Windows. This includes 1 for internet connectivity and 7 additional for Operator Apps. o This does not require device managed PDP contexts that the firmware may use for SMS and any other administration contexts. o Device firmware should be able to leverage host OS request for a PDP context that is already device managed internally in its firmware to be handled gracefully. o Device firmware should continue to abstract SMS PDP contexts and route them through the SMS CIDs regardless of the bearer used underneath. The Terminal shall support Voice, FAX, POS features via PS.

Priority is "preferred". For USB Sticks supporting VOX.

contacti ng their Microsof t interface Microsof t Partners can obtain the MBB Referen ce Docume nt by contacti ng their Microsof t interface
N/A

The Terminal shall support multiple

Required to support Voice, Fax, POS

simultaneous APNs / PDP contexts

features for backup or to allow the

with different Quality of Service. ( For user to get online before the Fixed-

example, a Voice APN could have two line connection is activated.

PDP contexts, one with Interactive Gold

QOS and the other with Streaming

Multiple APNs are required for

QOS. They can be Always-on and/or security reasons (to avoid exposing

On-demand).

voice APN to public internet because

it is connected to IMS Vodafone

In case of failure of IMS network, or in network) and for billing (data and

case of no data coverage (3g, GPRS), voice have different billing

the Terminal shall support Voice via CS. mechanisms based on APN

activation)

The Terminal shall support AT

Priority is "preferred".

N/A

commands to retrieve location

For USB Sticks supporting VOX.

information (i.e. Cell ID and LAC).

Location information is required to

resolve legal issue for Vodafone Italy.

It is not possible to use a Geographic

Number of a telephone district if you

are not physically there. This is an

issue as the VOX box is portable and

can be moved to other physical

locations. The location information

allows Vodafone to restrict voice

calls to the location that has been

registered.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Mobile Broadba nd OneNu mber
OneNu mber OneNu mber
OneNu mber Security
Security
Security
Security

Feature Vodafone OneNumber Vodafone OneNumber Vodafone OneNumber
Vodafone OneNumber GSM Security
GPRS Security
3G Security
LTE

Legal Emergency call support
Conne SIM ctivity connectivity

Functi Standalone onality calling
On- Provisioning boardi ng

User Experi ence

OneNumber

Cipher ing Algorit hms

GSM Ciphering Algorithms

Cipher ing Algorit hms

GPRS Ciphering Algorithms

Cipher ing and Integri ty Algorit hms

Ciphering and Integrity protection

Cipher ing and Integri ty Algorit hms

Ciphering and integrity algorithms

The Terminal shall support emergency calls (1) without SIM (2) with PIN locked SIM (3) when attached to a forbidden network.

Priority is "preferred". For USB Sticks supporting VOX. Required to fulfil legal requirements around emergency calls.

The device should have: either a classic SIM slot, compatible with Vodafone SIMs in the target markets; or an integrated eSIM module that can be provisioned with Vodafone eSIM profiles. The device shall be able to place and receive voice calls directly on the mobile network, without having to be connected to a primary device either via Bluetooth or remotely. Devices that are designed to be provisioned with the help of a primary device (eg. android app on the phone) shall support at least one of the GSMA pull or push methods. Custom activation journeys would have to be agreed but are not recommended. The operating system and possible companion app shall be designed with the concept of the secondary device having the same MSISDN as the user's primary phone. Ciphering algorithms shall be supported as specified in 3GPP TS 43.020. Refer to VVS (Vodafone Variant Settings) for further Vodafone OPCO roll out status. Clause 4.9 specifies which encryption algorithms are mandatory and which are optional. Ciphering algorithms shall be supported as specified in 3GPP TS 43.020, clause D.4.9. In addition, Vodafone requires support for GEA4 as a mandatory feature (not optional as TS 43.020 states). Ciphering and integrity protection as specified in 3GPP TS 33.102 shall be supported for all 3G capable devices. TS 33.102 clause 6.6.6 specifies which encryption algorithms are mandatory; likewise clause 6.5.6 specifies which integrity algorithms are mandatory. For the avoidance of doubt, the null integrity algorithm (that might be called "UIA0") must not be supported; and whenever applicable according to the standard, integrity verification on received messages must be enforced. For all LTE capable devices ciphering and integrity algorithms shall be supported as specified in 3GPP TS 33.401. Clause 5.1.3.2 specifies which encryption algorithms are mandatory and which are optional; likewise clause 5.1.4.2 specifies which integrity algorithms are mandatory and which are optional. For the avoidance of doubt, the null integrity algorithm (EIA0) may only be used for unauthenticated emergency calls; in all other contexts, whenever applicable

Devices without mobile connectivity, (e.g. wifi tablets) are not considered in the current phase of the MD proposition.
It's important to note that A5/4 is one of the mandated algorithms. Further, A5/2 must not be supported.

N/A
3GPP TS 43.020 3GPP TS 43.020 3GPP TS 33.102
3GPP TS 33.401

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Security Security Security
Security

Android
Application Security Bluetooth Security
Core Terminal

Bootlo ader
Gener al
Debug Ports

Unlocking the Bootloader
PC access to Locked Device
Protection against Unauthorised Access
OMTP TR0 Debug Port requirements

according to the standard, integrity verification on received messages (using a non-null algorithm) must be enforced. Unlocking the boot loader for Android devices shall be enabled only when the specific requirements as described in the reference document, Bootloader Unlock_Sept_2011.pdf, are satisfied.
When connected to a PC, if the device is locked when connected, no storage systems will mount.
It shall NOT be possible for an unauthorised person to access any information (e.g. phone book, calendar, images, etc) stored on the terminal without the user's knowledge or approval. Specifically, the terminal shall not be vulnerable to so called "Bluesnarfing" attack described in the public domain.
It shall NOT be possible for an unauthorised person to make phone calls or send/receive messages from the terminal using Bluetooth without the user's knowledge or approval.
All access to the terminal shall comply with the security requirements described in the Bluetooth specifications and Vodafone's Terminal requirements for Bluetooth Security. The terminal shall satisfy Debug Port requirements (DP1-5) in Section 7.2 of the OMTP Trusted Environment TR0 recommendations.
If the terminal is only partially compliant, please state which requirements are not satisfied.

Ensures that Vodafone is indemnified of obligations once the bootloader is unlocked. The bootloader unlock is to enable those customers who are technically willing/able to reflash their device to any software build they wish. This is only possible if the bootloader is not locked down as this controls the ability to manually flash software. Relevant to Android platform. - Applicable to Voice and Data devices - Applicable to all with tech but Mid to High with risk - Needed within Release Timescale - If non compliant, manufacturer must state why. Unless exceptional reasons provided, non compliance should not be acceptable as it allows an easy avenue for attack Description: Bluesnarfing is wellknown attack that affected mainly Nokia and SonyEricsson terminals in the past. Most of the problematic handsets have been reported to be fixed.
Priority: Mandatory
Non-Compliance Impact: It is critical that terminal is not vulnerable to any known attacks such as "Bluesnarfing". VF can not accept the terminal if it has a known Bluetooth vulnerability.
Description: A debug port allows external hardware and/or software to connect to ME debugging software components and on chip debugging support logic. This will typically allow run-time control, memory read/write access, access to trace information etc. As such, debug ports can be used to circumvent many security controls.
Impact: Access to software or hardware debug ports is likely to allow the security mechanisms that underpin features such as SIM lock and IMEI protection to be compromised. There is no reason to allow debug port access in consumer terminals. Non-compliance should be questioned. Partial compliance may be accepted depending on the explanation provided by the vendor.

Bootloa der Unlock_ Sept_20 11.pdf
N/A
N/A
OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Contact Person: Steve Babbage

Security Core Terminal Gener Protection of It shall not be possible for

Description: This requirement

N/A

al

low level

unauthorised modifications to be

ensures that the terminal cannot be

operation of applied to the software and/or

modified in such a way that could

communicatio hardware that controls the

cause radio interference in the

ns protocols communications parts of the terminal. network or other communication

This includes but is not limited to: GSM, channels.

3G, 4G, Bluetooth and Wi-Fi.

Priority: Essential

Security Core Terminal

Gener al Securi ty featur es

OMTP TR0 requirements on use of cryptography

Non-Compliance Impact: This is to avoid the device turning into a rogue device e.g. causing radio interference in the network or causing local interference, i.e. over WiFi.

The kind of things we would be concerned about would be where the code that encrypted data/voice communication was bypassed so that user privacy was compromised. Another example would be if mechanisms were bypassed, that were being used to authenticate the basestation the terminal is communicating with. This could leave the terminal open to "man in the middle" attacks.

The terminal shall satisfy cryptographic requirements (HU9-11) in Section 6.2 of the OMTP Trusted Environment TR0 recommendations.
If the terminal is only partially compliant, please state which requirements are not satisfied.

Basically we require any wireless access communications software to be protected against change to prevent generic threats which could take many forms. Description: Hardware Unique (HU) keys are used to support the secure implementation of critical mechanisms on the device, e.g. Secure Boot. The HU keys should meet the cryptographic requirements defined by the OMTP to ensure that they are resistant to cryptanalysis attacks.
Priority: Important
Non Compliance Impact: It is more likely that cryptanalysis attacks against HU keys could be successful. As such, the security critical mechanisms that rely on HU keys will be weaker. This functionality is starting to make its way into mobile devices and should be on vendors roadmaps. Non-compliance can be compromised but likely to become an essential requirement in the next requirements release.

OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Security

Core Terminal

Gener al Securi ty Featur es

Support for GAA server APIs

Security Security

Core Terminal Core Terminal

Gener al Securi ty featur es Gener al Securi ty featur es

Support for Trusted Execution Environment (TEE)
UE GBA procedure support

The device SHALL provide GAA server APIs according to the security guidelines in 3GPP TS 33.220. For this the support of AT +CSIM is required.
Support of Trusted Execution Environment (TEE) (e.g. ARM Trustzone) is strongly recommended
The device shall support the UE Generic Bootstrapping Architecture (GBA) procedures defined in 3GPP TS 33.220 for both GBA_U and GBA. 2G GBA as detailed in Annex I of 3GPP TS 33.220 is not required to be supported. Note: This does not mean no support for GBA over GSM. It means that 3G authentication for GBA should be used even when there is a GSM network. (Annex I is clear on this)

Important for supporting the latest authentication mechanisms
Trusted Execution Environment (TEE) is a validated security mechanism that will ensure protection of essential terminal security and application data management functions Allows the terminal/SIM to be authenticated by the network as part of the boot sequence

http://w ww.3gpp .org/ftp/ Specs/h tmlinfo/332 20.htm N/A
3GPP TS 33.220

Security

Core Terminal

Hardw are Uniqu e Key

OMTP TR0 HU key requirements

Where supported by the SIM the modem shall also support the protocol. The terminal shall satisfy HU key requirements (HU1-8) in Section 6.2 of the OMTP Trusted Environment TR0 recommendations.
If the terminal is only partially compliant, please state which requirements are not satisfied.

Description: Hardware Unique (HU) keys are used to support the secure implementation of critical mechanisms on the device, e.g. Secure Boot.
Priority: Important
Impact: The security of other security critical mechanisms, and therefore the overall terminal, is likely to be weaker. This functionality is starting to make its way into mobile devices and should be on vendors roadmaps. Non-compliance can be compromised but likely to become an essential requirement in the next requirements release.

OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

Security Core Terminal

IMEI Protec tion

OMTP TR0 IMEI protection requirements

The terminal shall satisfy IMEI protection requirements (IM1-12) in Section 8.2 of the OMTP Trusted Environment TR0 recommendations.
If the terminal is only partially compliant, please state which requirements are not satisfied.

Contact Person: Steve Babbage Description: Non-compliance suggests that vulnerabilities could exist, increasing the risk that the IMEI protection mechanism could be compromised.
Priority: Essential
Impact: The IMEI is used to blacklist stolen devices via the CIER. If the IMEI protection mechanism can be compromised, the IMEIs of stolen phones will be reprogrammed to stop them being effectively blacklisted. Unless IMEI protection mechanisms and the blacklisting mechanism are effective across Vodafone's terminal portfolio, IMEI blacklisting will not act as an effective deterrent to mobile phone

OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

theft. Contact person: Steve Babbage

Security Core Terminal IMSI IMSI exposure The terminal shall not expose the IMSI Description: This requirement limits N/A

Protec disallowed

or TMSI to the end-user or to 3rd party access to the IMSI to authorised

tion

applications.

applications.

Security Core Terminal

Secure OMTP TR0 Boot Secure Boot
requirements

The terminal shall satisfy Secure Boot requirements (SB1-10) in Section 11 of the OMTP Trusted Environment TR0 recommendations.
If the terminal is only partially compliant, please state which requirements are not satisfied.

Non-Compliance Impact: Probably the biggest risk of exposing IMSI is that it can be used as the NETWORKPIN for OMA DM/CP. This requirement helps prevent an OMA DM/CP attacker being able to discover a given user's IMSI by fooling the user to provide his IMSI via a social engineering attack, or by fooling the user into installing a 3rd party application which transmits IMSI to the attacker. Any noncompliance must be explained. Description: Secure boot mechanisms verify the authenticity and integrity of critical SW components such as the boot loader, the core OS and other security critical components such as the SIM lock mechanism and IMEI protection, when the terminal is turned on. Secure boot mechanisms may be used to underpin the verification of other SW components.
Priority: Essential
Impact: Non compliance is likely to mean that attacks which modify critical SW components aren't detected, leading to overall weaker platform security. Non or partial compliance may be accepted depending on the vendors explanation. Secure boot should be on vendors roadmaps.

OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

Contact Person: Steve Babbage

Security Core Terminal Secure Protection of The secure boot mechanism must

Description: The secure boot

N/A

Boot core operating prevent the unauthorised rollback to mechanism must prevent the

system

older versions of the OS core code and rollback to older versions of the

the loading of OS core code not

operating system core code.

intended for the terminal in question.

Priority: Essential

Security

Core Terminal

Secure Secure Boot Firmware
Update

Any authorised updates (e.g. Firmware updates) to code checked by the Secure Boot Process must include mechanisms to securely update the boot process, i.e. the terminal must implement a Flexible Secure Boot Process to avoid conflict with legitimate updates.

Non-Compliance Impact: Noncompliance could result in compromise of core code such as the OS as older versions on the OS core code may have been replaced in order to address security vulnerabilities. Description: Flexible Secure Boot compliments the secure boot mechanism by adding the possibility of modifying the code base checked as part of the secure boot process via an update code base image obtained via an over-the-air download or via some other connection to the

https:// www.gs ma.com /newsro om/gsm adocum ents/om tp-

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Security Core Terminal

Secure Verification of Flash downloaded
code

The terminal shall satisfy the Flexible Secure Boot requirements (ATE-FSB1140 to ATE-FSB-1310) in Section 6.4 of the OMTP Advanced Trusted Environment TR1 recommendations.
The secure flash download mechanism shall prevent roll-back to previous firmware versions unless the rollback has been authorised by the owner of the currently installed firmware.

terminal.
Priority: Important
Non Compliance Impact: Noncompliance will either mean that any component checked by the secure boot process cannot be modified or that the boot process is not secure. Either of these impacts is serious and may expose the used and Vodafone to security vulnerabilities (e.g. firmware can't be updated to fix known security issues or firmware can be updated to unauthorised (insecure) firmware. Vendors should be strongly encouraged to support this functionality. Description: We must be sure that all downloaded code is from a trusted source and is unmodified before being executed or installed
Priority: Essential

docume nts/
N/A

Security Core Terminal

Secure Flash Updat e

OMTP TR0 Secure Flash requirements

If the terminal supports a flash update mechanism, the mechanism shall satisfy Secure Flash requirements (SF15) in Section 13 of the OMTP Trusted Environment TR0 recommendations.
If the terminal is only partially compliant, please state which requirements are not satisfied.

Non-Compliance Impact: Noncompliance could result in the terminal being re-flashed with firmware that is known to contain security vulnerabilities. This could ultimately lead to the compromise of the terminals OS and other security critical mechanisms such as SIM lock and IMEI protection. Description: Secure flash mechanisms are used to provide a mechanism by which authorized parties can install code updates into the non-volatile storage of the terminal using the local interfaces of the ME. Typically serial ports or USB ports are used for this purpose. Secure flash mechanisms must not provide a way to bypass the other security mechanisms implemented by the terminal.
Priority: Essential

OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

Impact: Non-compliance may allow other security mechanisms - IMEI protection, SIM lock secure boot - to be bypassed, i.e. by allowing unauthorised code updates into the non-volatile storage of the terminal. There should be no reason for vendors not to implement flash mechanisms securely. Partial compliance may be compromised depending on the vendors comments.

Security

Core Terminal

SIM Lock Protec tion

Emergency SIM Lock

The state "Locked" or "Blocked" of a SIM-Lock shall have no influence on the emergency call function

Contact Person: Steve Babbage Global standardisation for SIM-Lock

3GPP TS 22.101 10 (Emerge ncy

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Security Security Security Security Security

Core Terminal Core Terminal Core Terminal Core Terminal Core Terminal

SIM Lock Protec tion
SIM Lock Protec tion
SIM Lock Protec tion
SIM Lock Protec tion
SIM Lock Protec tion

Language of displayed messages Lock Function
Lock Function Security
Lock Function Security - SIM Card
OMTP TR0 SIM lock requirements

Any malfunction and changes in the SIM-lock status are displayed immediately to the user. The output status message must be displayed in the language of the SIM-lock network or alternatively in English. The SIM Lock device is completely identical to devices without any Lock. SIM-card-lock: It means that each mobile device can be used only with a specific SIM-card. The device is bound by the configured in the device SIMlock on the activation and operation with exactly this SIM-card or SIM-cardnumber. If the card is not working or damaged, the device is no longer operational and it needs to be repaired. A SW update, upgrade or downgrade of the terminal must not change the SIMLock status of the device. It is to be excluded to deactivate the lockmechanism by reprogramming any eternal device memory. It is not possible to calculate the unlock-codes subsequently with help of the IMEInumbers. The mobile-code for SIMLock-data has to be completely ciphered on the device. Independently from the value in the administrative SIM data field "6FAD" (e.g. '81 00 00`), the SIM-Lock-mobile should only work, if additionally the valid entries in the IMSI data field "6F07" are out of the defined SIM-Lock ranges (MCC, MNC, HLR and Prefix) or the IMSI data field "6F07" has got the entry "MCC=001 MNC=01". The terminal shall satisfy SIM lock protection requirements (SL1-22) in Section 9.2 of the OMTP Trusted Environment TR0 recommendations.

Global standardisation for SIM-Lock
Global standardisation for SIM-Lock
Global standardisation for SIM-Lock
Global standardisation for SIM-Lock
Description: Non-compliance suggests that vulnerabilities could exist, increasing the risk that the SIM lock mechanism could be compromised. Impact: SIM lock is used to protect the Vodafone's subsidy of terminals in most European markets. Weak SIM lock mechanisms will allow the SIM lock to be removed. Impact for Embedded SIM (preferred): Why Required: To protect the partnership and revenue by preventing use of the device with other network operator SIMs.

Calls), 3GPP TS 22.022 Annex A2 N/A
3GPP TS 22.022
3GPP TS 22.022 14 (Security )
3GPP TS 31.102 4.2.18 EFAD (Adminis trative Data)
OMTP TR0, available from https:// www.gs ma.com /newsro om/gsm adocum ents/om tpdocume nts/

Security

Core Terminal

SIM Lock Protec tion

Unlock Function

The unlock-code must have minimum 8 digits, maximum 20 digits. After entering the unlock-code the SIMLock-device should be completely unlocked and there is no possibility to

What happens if not implemented? Loss of revenue Global standardisation for SIM-Lock

3GPP TS 22.022 14g (security )

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

change this unlockmode again. A

customer has five trials to enter the

unlock-code. After the 5th attempt

using a wrong code the device should

be blocked and it can only be

unblocked in the manufacturer service.

Security General & User User Phone access The terminal shall support a setting

Essential for security of user data.

N/A

Security

Data control

that requires password entry or other

Protec

user authentication to access the

tion

phone after turning it on.

Security General & User User PIN codes not PIN codes verified by the UICC ((U)SIM Description: This requirement

N/A

Security

Data stored on the or WIM) shall not be retained within the ensures that PIN codes destined for

Protec terminal or

terminal.

the SIM card cannot be intercepted

tion accessible by

and stored on the terminal.

downloaded It shall not be possible for applications

applications on the terminal or external applications

interacting with terminal UE at the time

of PIN entry to access/store PIN details Priority: Mandatory

as they are entered by the user.

Non-Compliance Impact: If a PIN is

retained, it could be possible for the

terminal (or an application on the

terminal) to reuse it without the

user's permission.

Security General & User User Telephony URI MMI codes as specified in 3GPP TS

Non support would result in a serious N/A

Security

Data Scheme and 22.030 as well device specific MMI

security breach

Protec MMI

codes (e.g. factory reset, network

tion

monitor, etc...) shall not be accessible

and executed by any external

application except for SIM applications.

The exception of SIM-application is

necessary since operator specific SIM

applications might use certain codes

(e.g. send USSD, ...) which shall not be

blocked.

Security General & User User User interface The terminal shall support a setting

Essential for security of user data.

N/A

Security

Data access

that locks the device after a certain

Protec timeout

elapsed time with no user activity,

tion

requiring password entry or other user

authentication to unlock it. A locked

device should still allow incoming calls

to be answered.

Security General

Certificate

The certificates supported shall be

Useful for developers & users to

N/A

Security

details must clearly listed and accessible in the

verify certificates.

Features

be listed to

device menu.

user

When listing the certificates, the

following relevant details of each one

must be shown:

Subject

Authority

Issuer

Valid from

Valid to

Certificate Type

Version

Serial Number

Signature Algorithm

Fingerprint

Security Network

TLS Displaying a The terminal shall display a warning to Description: This describes the UI

N/A

Protocols

Warning when the user informing them when the

behaviour of the terminal during a

transiting from terminal changes from https to http, i.e. TLS session.

https to http changes from a secure to a non-secure

session. An example of an appropriate

message would be "Connection no

longer secure"

Priority: Important

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Security Network Protocols

Non-Compliance Impact: If the

terminal does not show that a TLS

session has been terminated the user

may enter sensitive information in

the pages thinking that they are still

protected by TLS.

TLS Displaying

The terminal should be able to display Description: Displaying information N/A

details of any upon user request the Subject DN,

about the TLS session will give users

certificate in Issuer DN, Serial number, and Expiry

the ability to check the level of

the certificate date of all certificates in the certificate security provided.

chain

chain, i.e. all Server, Root CA or

Immediate CA certificates

Priority: Nice to have

Security Network Protocols

Non-Compliance Impact: This

functionality is likely to only be used

by security conscious users when

using applications such as

banking/m-commerce.

TLS

Initiate TLS 1.2 The terminal shall initiate TLS 1.2 or

Description: This is the expected

RFC

or higher when higher when making a request to a URL behaviour of any standard HTTP over 5246

using https

that starts with https:// as defined in TLS implementation. Further,

RFC 2818

upcoming industry-wide disabling of

TLS 1.0/1.1 is expected.

Priority: Essential

Security Network Protocols

TLS Signature algorithms

Non-Compliance Impact: Non

compliance will mean HTTP over TLS

Can not be used. Should be very

unlikely that any vendors are non-

compliant as this is a well established

behaviour.

The terminal shall be capable of

Description: This requirement is

N/A

verifying signatures made with RSA

needed to ensure support as a

keys including 3072 bits as a minimum. minimum for 3072 bit certificates for

improved security.

Priority: Mandatory

Security Network Protocols

Non-Compliance Impact: Non-

compliance will result in the terminal

not being able to verify some web

sites that use 2048 bit certificates.

TLS Support TLS In order to maintain the end to end

Description

N/A

1.2 or higher security at the transport layer while

tunnelling

using a proxy, TLS 1.2 or higher

This requirement is essential to allow

tunnelling shall be used between the TLS 1.2 or higher tunnelling via VF

client and the origin server.

Internet Gateways (proxies).

All mandatory requirements specified in A.2.3 Section of WAP TLS Profile and Tunnelling (WAP-219-TLS) Specification shall be Supported.

Priority: Mandatory

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Security 5G Security 5G

Security 5G

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Non-Compliance Impact

Cipher ing and Integri ty Algorit hms
Cipher ing and Integri ty Algorit hms
Cipher ing and Integri ty Algorit hms Generi c IMS functi ons for VoLTE and VoWiFi

Ciphering and integrity algorithms (dual connectivity)
Ciphering and integrity algorithms (NR standalone)
SUPI encryption
Implementatio n according to GSMA PRD IR.92

For all devices supporting dual connectivity between LTE and 5G NR, ciphering and integrity protection shall be supported as specified in 3GPP TS 33.401 clause E.3. Clause 3.10.1 specifies which encryption and integrity algorithms are mandatory and which are optional. For the avoidance of doubt, the null integrity algorithm (NIA0) may only be used for unauthenticated emergency calls; in all other contexts, whenever applicable according to the standard, integrity verification on received messages (using a non-null algorithm) must be enforced. For all devices supporting 5G NR standalone, ciphering and integrity protection shall be supported as specified in 3GPP TS 33.501. Clause 5.2.2 specifies which encryption algorithms are mandatory and which are optional; likewise clause 5.2.3 specifies which integrity algorithms are mandatory and which are optional. For the avoidance of doubt, the null integrity algorithm (NIA0) may only be used for unauthenticated emergency calls; in all other contexts, whenever applicable according to the standard, integrity verification on received messages (using a non-null algorithm) must be enforced. For all devices supporting 5G NR standalone, privacy protection of SUPI shall be supported as specified in 3GPP TS 33.501.
The Implementation of VoLTE and VoWiFi in the terminal shall be according to GSMA PRD IR.92 (latest version) This inlcudes: * The SIP registration process / IMS Authentication * Early Media (P-Early-Media header * Supplemenatry Services and Configuration (both MAP/CS and XCAP/Ut) * Explicit Call Transfer (ECT) Consultative * SIP Precondition Consideration * SMSoIP * AMR and EVS Speechcodecs * DTMF Events * RoCH * Radio Bearers * DRX mode * RLC configurations (UM, AM, QCI) * GBR adn NGBR Services

Non-compliance will mean that TLS sessions can not be initiated over Internet Gateways (Proxies).
Essential to adapt latest changes and recommendations in IR.92 (Version 10.0) to ensure compliance to our VoLTE implementation in NW.

3GPP TS 33.401
3GPP TS 33.501
3GPP TS 33.501
GSMA IR.92 Version 12.0 or later

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video Call Video

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & VoLTE Video

Generi c IMS functi ons for VoLTE and VoWiFi Generi c IMS functi ons for ViLTE
Generi c IMS functi ons for VoLTE Generi c IMS functi ons for VoLTE
Generi c functi ons for VoLTE

Domain selection - IMS PS voice preferred
Implementatio n according to GSMA PRD IR.94
Implementatio n according to GSMA PRD IR.64 Early Media
SUPL

* E-UTRA NR Dual Connectivity (5G Terminals) * Bearer Management for SIP, XCAP, Voice and Emergency Calls * Emergency Service * usage of well kown APN accoding IR.88 * Data Off and Services Availability * ISR (Idlemode Signaling Reduction) * SRVCC procedures (to 2G or 3G) * Roaming Considerations In case of non or partial compliance, please state the known limitations in the comment sections. The VoLTE and CSFB capable device shall support Domain selection: UE has the setting of "IMS PS Voice preferred, CS Voice as secondary". The feature must be available in order to assure that SMS, USSD, emergency calls and location can work in parallel to VoLTE service. The Implementation of Conversational Video Service the terminal shall be according to GSMA PRD IR.94 (latest Verion) in addition to IR.92 This Contains the support of: * Adding a "video" media feature tag in the REGISTER request * Support of H.264 Constrain Baseline Profile (CBP) Level 1.2 * Continue of a Voice call if the video GBR bearer is lost * Continue a Voice Call in case of SRVCC (i.e. keep the voice part and drop video media) In case of non or partial compliance, please state the known limitations in the comment sections. The Implementation of IMS Service Centralisation and Continuity of the terminal shall be according to GSMA PRD IR.64 (latest version) to support anchoring of IMS services (e.g. SRVCC) in CS domain. The UE must support reception of voice and video media associated with one early dialogue. The UE shall use the following method for early media (announcements, ringing tones) as described in 3GPP TS 24.628, chapter 4.2.2: Use early media as defined by IETF RFC 3960 and using the P-Early-Media header field authorizing early media as defined in IETF RFC 5009 for the gateway model. The other methods as "Alert-info" header field in the 180 (Ringing) response shall be ignored. The UE must support Secure User Plane Location Element (OMA SUPL 2.0) for geolocation information used for e.g. social presence Information SPI

Essential for all VoLTE terminals in order to allow Voice Service according to operators implementation.
Implementation according to GSMA Profile is applicable for all VoLTE Terminals supporting ViLTE to guarantee the maximum of interoperability.
Implementation according to GSMA Profile is applicable for all VoLTE Terminals to guarantee the maximum of interoperability.
Required for all VoLTE Terminals. This feature is required for launch of VoLTE, and is necessary in order to support "Ringback Tones". The use of P-Early-Media header prevents the exchange of early media between end users. Furthermore P-Early-Media shall be used when interconnect with other unknown SIP networks.
Required for all VoLTE Terminals, necessary to deploy geolocation services.

3GPP TS 24.008
GSMA IR.94 Version 13 or later
GSMA IR.64 Version 16 or later 3GPP TS 24.628 IETF RFC 3960 IETF RFC 5009
OMA SUPL 2.0

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & VoLTE Video

Voice & VoLTE Video

Voice & Video Call Video

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Generi c functi ons for VoLTE Generi c functi ons for VoLTE Generi c functi ons for ViLTE Generi c IMS functi ons for VoLTE

Semi Persistent Scheduling( SPS)
TTI bundling for voice
MBR must be greater than GBR
SIP INVITE with SDP-Offer

Generi c functi ons for VoLTE

NW generated dial tone

Generi c IMS functi ons for VoLTE

PANI Header

Generi c functi ons for VoLTE

Comfort Tones

Call Management manag of multiple ement calls

VoLTE capable terminals shall support Essential to support efficient VoLTE

Semi Persistent Scheduling

implementation in RAN.

VoLTE capable terminals shall support TTI bundling for voice to ensure good voice service coverage

Essential to support higher coverage for VoLTE.

Terminals supporting Video Telephony Essential to support good quality of over LTE shall utilise MBR values which service for Video over LTE. are greater than GBR values

The VoLTE UE must receive a SDP offer after each SIP INVITE message. Note: In case of INVITE without SDP offer the exchange of SDP Offer/Answer will be realised between 200 OK und ACK. According to RFC 3960 the User Agent (UA) is allowed to play early media packets even if a 200 OK was not received. This causes the risk of "media-clipping" - the cut of first media seconds. The VoLTE UE shall implement the early media and ringing tone generation according to IETF RFC 3960. The UE shall not generate local ringing tone unless 180 RINGING has been received and no incoming media has been received. In case 180 RINGING has been received and there are incoming media packets these shall be played instead of the local ones. The VoLTE UE shall send a PANI (PAccess-NW-Info) header containing the UE provided location information (as cgi) within SIP INVITE message. The information is relevant for services that require the LocInfo. The UE shall generate the following comfort tones: - Hold: (Tone pattern is similar to waiting tone described in GSM TS 02.40: 425Hz(400ms), Pause(8s) periodic - Busy: 425 Hz (500ms) , Pause (500ms) periodic - Ringing: 425Hz(1s), Pause (4s) periodic - MPTY Warning: 425 Hz (1s) - Special Info : 950Hz(330ms), 1400Hz(330ms), 1800Hz(330ms), Pause(1s) - Info: 425Hz(200ms),Pause (200ms), 3 cycles - CW: generated by MS only: analogue to Hold tone. It shall be possible for the user to manage single and multiple calls over LTE and WiFi in the same way as over circuit switched bearers, e.g. Reject,

Important to use Early Media as Ringbacktones and announcements without media clipping.
Important to establish local policy regarding ringing tone generation.
The information is relevant for services that require the LocInfo.
Comfort tones are not always supported by the NW. In order to offer the customer the same experience as with CS voice calls, the tone pattern for comfort tones shall be aligned with CS tone patterns as described in 3GPP TS 22.001
Essential for consistency of user capabilities for call management etc. across different bearers. Non compliance means potentially

TS.36.32 1 TS.36.32 1 N/A IETF RFC 3960
IETF RFC 3960
IETF RFC 3455 N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video Voice & Video Voice & Video
Voice & Video
Voice & Video

WiFi Calling and messaging WiFi Calling and messaging WiFi Calling and messaging
WiFi Calling and messaging
WiFi Calling and messaging

Messa ging
Messa ging
Emerg ency calls
Emerg ency calls
Generi c IMS functi ons for VoWiFi

SMS over WiFi Bearer
SMS over CS bearer while connected to VoWiFi capable WiFi network Emergency Call Notification
Emergency call according to GSMA IR.51
Implementatio n according to GSMA PRD IR.51

Hold, Merge, etc. The terminal shall support a unified UI integrating legacy and new Call management interfaces - Circuit Switched, VoLTE, Call+ etc. This shall include the same ringtone to be used for incoming calls, and logging of calls in call history logs. The terminal shall support mobile originated and mobile terminated SMS over WiFI bearer consistent with mechanisms used over circuit switched bearer A terminal shall support SMS over any available cellular bearers while being simultaneously connected to VoWiFi bearer for voice services
The customer shall be informed that emergency calls might not work properly via VoWiFi, especially in areas with no 2G/3G coverage by any operator.
An appropriate message (text as specified in reference document by VF DE team) need to be presented on the UE before using the Service. Proposed solution: - Customers get a notification windows every time the UE contacts the ePDG. - Customer has to click "OK" to confirm limited emergency call availability in order to use the service, otherwise Wi-Fi Calling is disabled - Customer can supress the notification window in the future by clicking "do not show again". The terminal shall support emergency sessions for VoWiFi as profiled in IR.51 (latest version): "The UE must support Annex J of 3GPP Release 13 TS 23.167, Annex R of 3GPP Release 13 TS 24.229 (for SIP procedures), and 3GPP Release 13 TS 24.302 (for selection of ePDG for emergency services and for establishment of emergency PDN connection via untrusted EPCintegrated WLAN)." The Implementation of VoLTE and VoWiFi in the terminal shall be according to GSMA PRD IR.51 (latest version) This inlcudes: * SIP Registration Procedures * Mobility (VoLTE-VoWIFI HO) * Supplementary Services * Fast-reauthentication * Messaging (SMS) * non-3GPP Access Authentication and Security * APN Considerations for SIP Signalling and XCAP In case of non or partial compliance, please state the known limitations in the comment sections.

poor integration of WiFi Calling and other call management interfaces (legacy circuit switched, VoLTE, Call+).
Based on market support for IMS messaging, referenced in VVS
Notification for end user for emergency call scenarios. Legal requirement for the German market.
VF Germany is obliged by Regulation to support IMS based emergency calls over VoWiFi and VoLTE by 2.H 2019. Risk of being forced to switch off service if not supported.
a. Non compliance would mean no support of WiFi Calling and Messaging using untrusted WiFi networks b. Failure to comply will result in poor call coverage when terminal is moving in and out of WiFi coverage c. Without fast re-authentication an optimized signalling for re authentication is not possible d. Essential for consistency of user capabilities for call management etc. across different bearers

VVS
N/A
UX VoWiFi VF DE Emerge ncy call docume nt_June 17.pdf VVS
GSMA IR.51 Version 6.0 or later
GSMA IR.51 Version 6.0 or later

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video Voice & Video Voice & Video
Voice & Video
Voice & Video
Voice & Video

VoLTE IMS Voice (VoLTE & VoWiFi) IMS Voice (VoLTE & VoWiFi)
WiFi Calling and messaging
IMS Voice (VoLTE & VoWiFi)
IMS Voice (VoLTE & VoWiFi)

Emerg ency calls
Supple menta ry Servic es via IMS Supple menta ry Servic es via IMS
Emerg ency calls
Generi c IMS functi ons for VoLTE and VoWiFi Emerg ency calls

Emergency cause value in RRC connection request CW configuration
Ut authentication and authorization
Emergency call over VoWiFi Location Information
Implementatio n according to GSMA PRD IR.88
sos APN

The terminal shall support the sending of Emergency cause value in an RRC connection request This is also required for current devices.
The VoLTE terminal shall support network-based service for Communication Waiting. This is in addition to current GSMA IR.92 proposed terminal-based service for CW. In order to authenticate and authorize the subscriber for Ut usage, GBA based authentication shall be supported by the VoLTE terminal
The terminal shall support emergency sessions for VoWiFi including location information according to GSMA IR.51 v6.0: "The UE must support the current location discovery during an emergency call as specified in subclause 5.1.6.8.2, subclause 5.1.6.8.3, subclause 5.1.6.8.4, and subclause 5.1.6.12 of 3GPP Release 14 TS 24.229" * The P-Access-Network-Info (PANI) header allows to identify a call attempt as coming from the WiFi access network (in contrast to 4G/LTE). * The Cellular-Network-Info (CNI) header will provide the last-known CellI D which will be the one and only piece of information used by the network operator to determine the correct PSAP (emergency center). It may / should contain a timestamp indicating when the last network contact has been made. The P-Cellular-NetworkInfo would provide the same information as the Cellular-NetworkInfo header. Newer implementations should use the standardized CNI rather than the P-CNI header. * The Geolocation header with its associated message (XML) body can be used by the terminal to convey additional location data (such as a geocoordinate) which will be passed to the PSAP transparently. The UE shall use Access Point Name (APN) according to GSMA PRD IR.88 (latest version) for: * IMS based Services (IMS) * IMS Emergency calls (SOS) In case of non or partial compliance, please state the known limitations in the comment sections. The UE shall support the new "sos" APN provided by the network.

Essential to comply with legal obligation to provide an emergency call facility Network based service for CW is essential to support Vodafone Enterprise Services.
Essential for all VoLTE terminals in order to allow supplementary services with IMS.
VF Germany is obliged by Regulation to support IMS based emergency calls over VoWiFi including the location information by 2.H 2019. Risk of being forced to switch off service if not supported.
Essential to adapt latest changes and recommendations in IR.88 (latest Version) to ensure compliance to our VoLTE implementation in NW.

3GPP TS 36.331
N/A
3GPP TS 33.220, TS 33.222, TS 24.109 and TS 29.109 GSMA IR.51 version 6.0
GSMA PRD IR.88 Version 18 or later

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Emerg Emergency ency PDN calls

Emerg ency calls

IMS Emergency Call and Domain Priority

Voice & Video

WiFi Calling

Emerg Location -

and messaging ency Cellular-NW-

calls Info (CNI)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Emerg Emergency ency Registration calls Conditions

For UE detected emergency call, the UE shall set up an emergency PDN connection with the information provided by the network.
The UE has to support and handle VoLTE and VoWiFi emergency call on IMS according to 3GPP TS 23.167 and TS 24.229. The UE shall not issue an emergency call over WiFi if the emergency call can be established via 3GPP access, according to 3GPP TS 23.402 (Rel-13 and later) The UE shall select the domain to perform an emergency call considering the following priority list: 4G/3G/2G (accordingly to GSMA IR.92 and 3GPP TS 23.167, Annex H). Accordingly to 3GPP TS 23.402, chapter 7.4.4, the UE shall address an emergency call under WiFi as a last resource, only if no 3GPP access is available, regardless the carrier prioritization for normal calls. UE compliant with TS 23.402, Rel-14 shall attempt to address the emergency call under 4G/3G/2G coverage from another network operator, in case no 3GPP access from their own network operator is available. In any case, also devices compliant with TS 23.402 previous releases shall always consider WiFi as the last resource to address an emergency call. The UE shall send the CellularNetwork-Info (CNI) or the P-CNI in the INVITE message. In this parameter the last Cell-ID field shall be properly set. The last Cell-ID provided by the UE is used to route the call towards the proper PSAP, in case of VoWiFi. In case of no or invalid Last Cell-ID information, the emergency call will be rejected by the CRS. For a UE detected emergency call the UE shall initiate an IMS emergency registration, before starting the emergency call, when all of the following conditions are met: - either the UE is not already IMS registered or the UE is IMS registered but is roaming outside its home network; - the UE has sufficient credentials to authenticate with the IMS network; - the UE is able to detect emergency session Therefore, for a UE with no credentials for the IMS authentication, the UE shall skip the emergency registration and directly initiate the emergency call, with the indication "anonymous user". The UE shall also initiate an IMS emergency registration when it receives an "IMS emergency registration required" response as a result of the emergency session request.

VF Germany is obliged by Regulation to support IMS based emergency calls over VoWiFi including the location information by 2.H 2019. Risk of being forced to switch off service if not supported.
For VoWiFi scenario, the risk is that the last cell id is not the real one. In case the customer is in a total different location (due to switched off UE during travel) the call could be routed towards a wrong PSAP.
The emergency registration procedure is important to guarantee the availability of the MSISDN to allow the callback from the PSAP. In case of no emergency registration (emergency call as "anonymous user") the callback from the PSAP is not possible. The UE expected behavior is to always perform the emergency registration before the emergency call, unless it is aware not to have sufficient credentials.

3GPP TS 23.167, Annex H 3GPP TS 24.229 3GPP TS 23.402

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Voice & VoLTE Video

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Emerg Emergency ency Registration calls Request

Emerg ency calls

Emergency Registration Parallel Registration

Emerg Emergency ency Attach calls Procedure

Emerg ency calls

INVITE - UE Detected Emergency Call

In case of emergency IMS registration failure the UE shall be able to interpret the indication that anonymous IMS emergency sessions are supported (if present) and the UE shall proceed with an anonymous IMS emergency session. In case the network rejects the emergency registration without giving any indication to the UE, the expected behavior for the UE is to start the emergency call as anonymous. For an emergency registration request, the UE shall indicate that it is an emergency registration adding "sos" in the Contact field in the Request-URI of the REGISTER message. For the emergency registration, the UE shall properly populate the From and To header fields of the REGISTER request with: the first entry in the list of public user identities provisioned in the UE (if present) or the default public user identity obtained during the normal registration (if the UE is not provisioned with a list of public user identities, but the UE is currently registered to the IM CN subsystem) or the derived temporary public user ident (in all other cases). As for standard, in case the UE had already a normal IMS registration and then performs an emergency registration, the UE shall be able to maintain in parallel both the normal and the emergency registration. For VoLTE emergency calls, if the UE is not attached to EPS, the UE shall first initiate an emergency attach procedure.
For a UE detected emergency call, in the INVITE request the UE shall properly set: - Request-URI: including service URN ("sos") - To header field: with the same emergency service URN as in the Request-URI - From header field: in case the user has successfully performed the emergency registration it should include the public user identity registered or the tel URI associated with the public user identity registered. In case the user did not success or was not able to perform the emergency registration, it should set this field as "anonymous" - Triggered as VoLTE emergency call directly. The UE will send an Emergency Attach request to the enodeB if not already attached. The attach type and request type will be "Emergency". If already attached then an Emergency PDN connectivity procedure will be followed with the request type set to "Emergency".

The emergency registration procedure is important to guarantee the availability of the MSISDN to allow the callback from the PSAP
The UE behavior is expected as per standard (TS 23.167, TS 24.229) Especially, both 110 and 112 shall be considered as detected emergency number.

3GPP TS 23.167 3GPP TS 24.229

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video

IMS Voice (VoLTE & VoWiFi)

Emerg INVITE - IMEI ency Information calls

For emergency INVITE, the UE shall send the IMEI information

The IMEI is used to anchor the call on 3GPP TS

EATF.

24.229

Voice & Video
Voice & Video
Voice & Video
Voice & Video Voice & Video
Voice & Video

IMS Voice (VoLTE & VoWiFi)

Emerg Emergency ency Call calls Termination

WiFi Calling

Emerg List of

and messaging ency Emergency

calls Numbers

WiFi Calling and messaging

Transp ort Securi ty

IPSEC support for IMS transport for WiFi Calling related functions (voice and messaging)

WiFi Calling

User User

and messaging Interfa management

ce

of WiFi Calling

WiFi Calling and messaging

Config uratio n

Priority of bearers cellular and WiFi

WiFi Calling

User Notification of

and messaging Interfa WiFi bearer

ce

and Wifi calls

As for standard, after the emergency call is completed the UE shall stop refreshing the emergency registration. When the emergency registration timer expires on the UE, the UE shall initiate EPC default bearer termination procedure. The UE shall be able to understand the list of emergency numbers provided by the network and use the proper subservices as indicated by the network. Especially the following numbers shall be considered as emergency number including their subservices: - sos.police for 110 - sos.fire for 112
The terminal shall support IMS IPSEC transport of data towards the ePDG. This shall be implemented according to the local OpCo requirements (VVS).

Note: It is still under investigation if the default bearer supervision feature in the P-CSCF could be used
This requirement reflects current NW behaviour which states that the network shall inform the UE about the local emergency number. Note that at this moment the Cisco ePDG is not able to inform the UE about the local emergency number list, so it is expected that in case of VoWiFi (without a previous attach to 4G) the UE will start a call towards 110 as a normal call and then it will be asked by the P-CSCF to perform the emergency registration. Required to ensure mobile class security of voice and messaging data

3GPP TS 24.229, Annex B.2.2.6.1
VVS

ePDG certificate handling:

The terminal shall support ePDG

Certificate Request (CERTREQ/38

(RFC7296)) and handling of IKEv2

Critical Bit for CERTREQ. This shall be

implemented according to the local

OpCo requirements (VVS).

If enabled via the network

Essential to allow user control of the N/A

configuration, it shall be possible for WiFi Calling solution

the user to enable/disable WiFi Calling

in the user interface. The default

setting shall be WiFi Calling disabled.

The terminal shall be configurable

Failure to comply will mean that

VVS

such that the priority of bearers for

there is no flexibility to manage the

Voice and Messaging can be adjusted connection preferences

between WiFi and cellular bearers.

Configuration shall be as determined

via VVS settings, and not through the

terminal user interface. Default call

priority, if not specified in VVS, shall be

4G-3G-2G-VoWiFi

For incoming and outgoing voice calls Needed to manage user expectation VVS

the user interface shall provide

of call quality and lack of handover.

confirmation that the call is to be made Best effort for initial products

over WiFi bearer. This shall take the

form of an indication of the connected

bearer, by displaying the Vodafone

Service name as specified per VVS, in

the status line when the terminal is IMS

registered to the Vodafone network

through WiFi. When a call using the WiFi

Bearer is in progress, a permanent

indication shall be present in the

terminal UI that indicates the bearer in

use.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video Voice & Video
Voice & Video
Voice & Video Voice & Video
Voice & Video

VoLTE VoLTE
VoLTE

Generi c functi ons for VoLTE Generi c functi ons for VoLTE

SR-VCC to 3G+PS Handover to 3G
LTE Call reestablishment

Supple menta ry Servic es

Supplementar y Service Configuration when Ut data connection not available

VoLTE

Generi c IMS functi ons for VoLTE

No IMSI in IMS Registration request

WiFi Calling and messaging

Remot e VoWiFi Servic e Provisi oning by Netwo rk

VoWiFi Provisioning

WiFi Calling and messaging

Call manag ement

Terminal based VoWiFi roaming management

The VoLTE capable device shall support SR-VCC from LTE layer towards multi-RAB

Allows Multi-RAB calls to continue using 3G when moving out of LTE coverage. Essential for LTE smartphones

3GPP TS 23.216

LTE Call re-establishment needs to be supported in the same way as it's been supported for years in 2G and 3G. The difference is that the reestablishment is now executed of a PS domain (LTE) as part of VoLTE
1. The UE shall ALWAYS try Ut interface as first option, i.e. when under 4G/3G/2G coverage, with DATA ON or OFF, Wifi ON or OFF, when under HOME NETWORK OPERATOR and when ROAMING. 2. In any scenario, use ALWAYS 3GPP TS 24.010 as backup option in case of Ut failure, i.e.: - The APN used for UT cannot be activated - The Ut interface is NOT reachable (DNS query failure or NO answer to HTTP request); - The UE is receiving 403 or 5xx error causes to the HTTP XCAP query. - In case the reject cause is permanent the UE shall use TS 24.010 till the next restart as indicated in IR.92 and TS 24.623 Rel-12 - In case the reject cause is temporary the UE shall use TS 24.010 for the current transaction and retry XCAP/Ut for the next transaction. The contact header communicated by the UE during IMS Registration shall include the IP-address but not the IMSI. Unnecessary signalling of the IMSI, e.g. during terminating SIP INVITE, must be avoided. The device should have the capability to allow VoWiFi Service provisioning/deprovisioning by means of an SMS message compliant with the Vodafone VoWiFi FQDN Provisioning Specification. This function shall be implemented according to the local OpCo requirements (VVS).
Handling invalid FQDN information: If the NW sends an invalid FQDN information, the UE should keep the IMS to stay in LTE and will not activate VoWiFi The device should have the capability to block WiFi calling in roaming. The setting should not be visible in the UI and be implemented according to the local OpCo requirements (VVS).

Lack of support in LTE for VoLTE would create a worse user experience for VoLTE vs 2G or 3G CS call when for any reason the radio connection is temporary lost (e.g. terminal moving across tunnel with bad coverage or non-optimized neighbours) The fall back to MAP is essential in case a data connection to Ut is not available (e.g. due to roaming tariff)
Essential for VoLTE voice services to minimize signalling containing the IMSI.
Without this mechanism terminals that are not used with an appropriate tariff may attempt to access the Voice over WIFi service, causing overload on the WiFi AAA server. The corresponding deprovisioning mechanism allows Vodafone to manage terminals that are no longer permitted to use VoWiFi
VoWiFi will be usable when roaming if not implemented, and subsequent impact on roaming revenues. I.E. no roaming restriction.

N/A
3GPP TS 24.010 3GPP TS 24.623 Rel-12 GSMA IR.92 latest version
3GPP TS 24.229
"VoWiFi Provisio ning Utilising SMS"
VVS

Basic mechanism 1. If the terminal only detects cellular NW's with non home country code, the device should block WiFi calling 2. If the terminal detects via any geo

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

location function, that the user is

outside the home country, the device

should block WiFi calling

3. In case the device can't determine

based on 1. and 2. (i.e. in flight mode,

no coverage areas), WiFi calling should

be blocked if the last stored Terminal

location information is outside the

home network

Voice & WiFi Calling

Cellula Cellular bearer The terminal shall apply a signal

Essential to ensure that terminals

VVS

Video and messaging r QoS QoS

strength threshold for selection of

select WiFi for VoWiFi access when

manag management Cellular bearers (4G, 3G, 2G) and WiFi existing cellular signal is weak

ement for access of when this is available for VoWiFi.

VoWiFi service Note that the threshold levels will

differ from the usual level at which a

terminal would attempt to access

another cellular bearer. The threshold

levels apply to all cellular bearers used

for voice services, whether CS voice on

2G or 3G bearers, or VoLTE on a 4G

bearer.

The threshold levels are defined on a

market by market basis and are

documented in the VVS as these will

vary according to frequency usage and

network coverage conditions in each

market.

Voice & Video
Voice & Video

WiFi Calling and messaging
WiFi Calling and messaging

ePDG IP addres s range
VoWiFi Backof f timer

VoWiFi ePDG address range
VoWiFi backoff timer (handling)

The use cases covered by these threshold values are: Cellular -> Cellular Cellular -> WiFi Cellular -> No service The terminal shall support 3GPP 24.302, v.13.6.0, 7.2.1.3 : "...Upon reception of a DNS response containing one or more IP addresses of ePDGs, the UE shall select an IP address of ePDG with the same IP version as its local IP address. If the UE does not receive a response to an IKE_SA_INIT request message sent towards to any of the received IP addresses of the selected ePDG, then the UE shall repeat the ePDG selection as described in this subclause, excluding the ePDG for which the UE did not receive a response to the IKE_SA_INIT request message. The terminal shall support the error handling as described in 3GPP 24.302, v14.2.0 chapter 7.2.2.2: a. if no BACKOFF_TIMER Notify payload is included in the received IKE_AUTH response message from ePDG, then the UE shall start an implementation specific backoff timer of 30 min b. specifically handling of the BACKOFF_TIMER Notify payload together with the Notify Payload with Private Notify Message Error Type "NO_APN_SUBSRIPTION"

Necessary to support redundancy. This terminal requirement ensures failover to alternative ePDG in case of primary ePDG outage. Alternative failover mechanism by ePDG availability detection through DNS is not possible due to IKE.
a. Necessary to control access request to Wi-Fi in the same way than in 3G and 4G (requested backoff timer in Wi-Fi is equal to backoff timer T3396 used for NAS cause #33 and #27). Autoprovisioining process relies on the terminal repeating the access request and the user experience must be the same in 3G/4G than in Wi-Fi. At the same time the operator needs to be able control the load/TPS on ePDG/AAA/HSS. b. Error handling description in 3gpp 24.302, v14.2.0., Preferred method to have control of backup timer and thus network load from network side.

N/A
3GPP 24.302, v14.2.0 chapter 7.2.2.2

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & WiFi Calling

VVS VVS reference Terminal shall support the country

VVS

Video and messaging refere

specific settings for the service

nce

configuration and correct operation on

Vodafone network.

Afore mentioned settings can be

access using the latest version of VVS

(Vodafone Variant Setting repository)

##insert VVS database hyperlink for OEMs##

Voice & Legacy Voice Video Voice & SIMs and Video USIMs
Voice & Legacy Voice Video
Voice & Legacy Voice Video
Voice & Legacy Voice Video

Phone Book
Dual SIM
Voice Qualit y Requir ement s
Voice Qualit y Requir ement s
Voice Qualit y Requir ement

Add country code to contact number when roaming Call log integration
Audio performances
HD-Voice
Static and non static noise cancellation for headsets

(note: in case you do not have access, please request it to your Vodafone counterpart) In case some settings cannot be supported or configured country per country: please state all limitations in the comment section The device should automatically recommend or insert the appropriate country code (e.g. +44) in front of a contact number stored within the phonebook. In a Dual SIM capable terminal the call log (dialed calls, received calls, missed calls) shall indicate which SIM (Primary or Secondary) was in use for each entry
The device shall support noise cancellation (Software and Hardware) and audio enhancement technologies in order to meet all acoustic performance thresholds as defined in: -GCF Performance Data Package PDP Acoustic. -Vodafone Acoustic Performance Measurements document (current version VFTST_1.020_Acoustics). Note that for devices with WB-AMR speech coder enabled, the highest targets should be achieved , especially for BGNT. Devices capable of WB-AMR must be HD-Voice certified (according to the GSMA HD-Voice certification regime) This requirement does not impact the Acoustic KPI requirement
The terminal used in Headset mode shall implement "Noise Suppressor" for calls in order to reduce surrounding noises included in sounds which are collected by the microphone.

Enhanced user experience to allow the user to use the device contacts when roaming without having to amend the phone number Only to be supported in terminals as requested by Vodafone Portfolio management team and specified in the device TPD. This Dual SIM requirement is to be applied to specific Vodafone Branded (VFD) terminals for specific markets, NOT generally applied. Required to keep Acoustic performance high
With the HD-Voice certification a minimum of audio quality level is assured by the manufacturer
To improve the quality of the voice for the users using headsets.

N/A
N/A
VFTST_1 .020_Ac oustics.p df, Acoustic KPI test excecuti on spreadsh eet_v06. 06.2013. xls, GCF PDP
Minimu m Technic al Require ments for use of the HD Voice Logo with GSM/U MTS/LT E issued by GSMA Version 1.1 (VT14) : VFTST_1 .020_Ac oustics.p df

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video Call Video
Voice & Video Call Video
Voice & Video Call Video
Voice & Video Call Video
Voice & Video Call Video

s

Video call native entry points integr ation Video call native entry points integr ation Video call native entry points integr ation Video call native entry points integr ation

Video call approved services
Video call native entry points location
Video call native entry points branding
Video call native entry points - green button experience

Video call native entry points integr ation

Video call native entry points services integration

Please see: Acoustical Quality Evaluations of Terminals VFTST_1.020_Acoustics.

Note: This requirement applies for headsets in wired or wireless connection (e.g. Bluetooth). Note2: The Headset mode describes the Terminal used when connected to a headset and the communication is done via this external accessory. For details please refer to VFTST_1.020_Acoustics At requirement creation, Vodafone approved Video Call services are ViLTE (first priority) and Facetime/Duo (second priority). Native Video Call Entry Points shall only link to video services that are approved by Vodafone. Native video call entry points shall be provided next to each Native Voice Calling / Messaging entry point (i.e. within Messaging, Contacts, Call Log)

Required to only offer video calling when a good video call experience is feasible
Required to only offer video calling when a good video call experience is feasible

Native video call entry points shall not be branded (e.g. no Facetime/Duo label shall be shown and device native video call glyphs shall be used in line with messaging and calling glyphs)

Required to only offer video calling when a good video call experience is feasible

Native video call entry points shall only be shown if there is sufficient likelihood for a Video Call to the respective contact to be successful. *For ViLTE calls, the likelihood for success is sufficient if: 1.- The respective contact was discovered as ViLTE capable within the last 30 days (SIP OPTIONS return ViLTE capability or device already received ViLTE call from respective contact or the device received ViLTE capabilitie during a VoLTE call) 2.- in case ViLTE capability is unknown, then try an error maybe used as a capability check to determine if the contact is ViLTE or is not. *For Duo Video Calls, the likelihood for success is sufficient if the contact was discovered as Duo capable within the last 30 days (using Google Duo APIs) or if Duo wasn't yet set up on the device. The video call entry points shall combine all approved Video Call services that are available on the device in the respective market. When the user selects the Native Video Call entry point and multiple services are available, the device shall seamlessly try establishing video calls service by service according to the respective priority (see previous requirement). If no Video Call could be established, the

Required to only offer video calling when a good video call experience is feasible
Required to only offer video calling when a good video call experience is feasible

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Voice & Video Call Video

Voice & Video Call Video

Voice & Video Call Video

Voice & Video Call Video

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT NB-IoT LTE

Video call native entry points integr ation
Video call native entry points integr ation
Video call native entry points integr ation Video call native entry points integr ation RAN Sharin g
RAN Sharin g
Gener al

Video call native entry points - service setup
Video call native entry points invitation flows
End of Video call flow
No 3G Circuit switched Video call button from dialer, call logs, contacts, when RCS available MOCN - LTEIoT
MOCN - NB-IoT
FGI bit pattern for Rel-9 onwards, bit 33-64

device shall seamlessly fall back to an operator voice only call (e.g. VoLTE) and display a respective toast message to the user.
If Duo wasn't yet set up on the device, and the user selects the Native Video Call entry point, and higher priority Video Call services could not be used; then the user should be offered setting up Duo. o If the user sets up Duo, the Duo setup request will not appear again later and the device tries setting up a Video Call using Duo. o If the user does not agree setting up Duo, the Duo setup request will appear again next time and the device will try with the next priority (e.g. fall back to voice call). Using Native Video Call entry points, there shall not be any video calling service invitations flows available (e.g. if the other party doesn't support video calling, the user shall not be offered sending an invitation to his contact to install/enable a video calling service/app). Once a Video Call is finished, the UI shall return to the point where the Video Call was initiated (e.g. Messaging, Contacts, Call Log). There shall be no need to tap a button to exit the Video Calling UI / app.
As 3G Videocall service will be shortly interrupted in the networks. There should be no button to initiate a 3G Circuit switched Video call from dialler, call logs, contacts.
The system support MOCN (MultiOperator Core Network) functionality with up to 3 operators with CAT-M with no restrictions
The system support MOCN (MultiOperator Core Network) functionality with up to 3 operators with NB-IoT with no restrictions
The following bit pattern (TS 36.331, Annex B, Table B.1-1a) shall be at least supported by the UE: FGIbit 33: X (IRAT ANR UTRAN FDD) bit 34: 1 (IRAT ANR GERAN) bit 35: X (IRAT ANR 1xRTT) bit 36: X (IRAT ANR HRPD) bit 37: X (IRAT ANR UTRAN TDD) bit 38: X (PSHO if UTRA TDD&FDD) bit 39: X (B2 if UTRA TDD&FDD) bit 40: X (CSHO if UTRA TDD&FDD) bit 41: X (B1 if UTRA TDD&FDD) bit 42: X (DCI3a) bit 43-64: undefined

Required to only offer video calling when a good video call experience is feasible
Required to only offer video calling when a good video call experience is feasible
Required to only offer video calling when a good video call experience is feasible
Required to only offer video calling when a good video call experience is feasible
Allows terminals to utilise Core Network on shared networks
Allows terminals to utilise Core Network on shared networks
Required for essential NW features, and for NW planning and testing issues in order to select test cases.

N/A
N/A
N/A
3GPP TS 36.331 Annex B

-The FGI bits marked with "X" are not

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity
Wide Area Connect ivity Wide Area Connect ivity
Wide Area Connect ivity

LTE

Capaci Downlink E-

ty

PDCCH

LTE - Voice

CSFB

and Messaging

LTE

Gener

al

CSFB to UTRAN with Deferred Measurement Control Reading FGI bit pattern Rel-10 onwards, bit 101-132

LTE

Gener FGI bit pattern

al

for Rel-9

onwards, bit 1-

15

required to be set. This pattern is valid for all UE from Rel-9 onwards. - In case of non or partial compliance, please state the known limitations in the comment sections. The UE shall support DL E-PDCCH according to 3GPP Rel-11.
CSFB to UTRAN with Deferred Measurement Control Reading 3GPP TS 25.331.
The following bit pattern (TS 36.331, Annex C.1, table C.1-1) shall be at least supported by the UE: FGIbit 101 - X bit 102 - X bit 103 - X bit 104 - X bit 105 - X bit 106 - X bit 107 - X bit 108 - X bit 109 - X bit 110 - X bit 111 - 1 (CA) bit 112 - 1 (CA) bit 113 - X bit 114 - 1 (simult. RSCP and EcN0 report) bit 115 - X bit 116 - X bit 117 - 132 undefined - The FGI bits marked with "X" are not required to be set. This pattern is valid for all UE from Rel-10 onwards. - In case of non or partial compliance, please state the known limitations in the comment sections. The following bit pattern (TS 36.331, Annex B, Table B.1-1) shall be at least supported by the UE: FGIbit 1: X bit 2: 1 bit 3: 1 (VoLTE:RLC UM & PDCP SN) bit 4: 1 (short DRX) bit 5: 1 (long DRX) bit 6: 1 (prio bitrate) bit 7: 1 (VoLTE: RLC UM) bit 8: 1 (4G > 3G HO) bit 9: 1 (VoLTE) bit 10: 1 (4G > 2G CCO + NACC) bit 11: X bit 12: X bit 13: 1 (interFreq meas 4G) bit 14: 1 (Event A4, A5) bit 15: 1 (UTRAN Meas, Event B1) - The FGI bits marked with "X" are not required to be set. This pattern is valid for all UE from Rel-9 onwards.

Feature helps reduce congestion when high traffic load in hotspot areas creates congestion in the PDCCH. Essential that we build device penetration of this feature as at NW level the benefit of this feature is linked to the device penetration Important to reduce the call setup time. Support requested today.
Required for essential NW features, and for NW planning and testing issues in order to select test cases.
Required for essential NW features, and for NW planning and testing issues in order to select test cases.

3GPP TS 36.211
3GPP TS 25.33 1 3GPP TS 36.331, Annex C
3GPP TS 36.331, Annex B

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

- In case of non or partial compliance, please state the known limitations in the comment sections.

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE - Voice and Messaging
LTE - Voice and Messaging LTE - Voice and Messaging LTE
LTE - Voice and Messaging
LTE LTE
LTE LTE

USSD IMS USSD via IMS

CSFB CSFB indication in Paging Response message

CSFB
Gener al

Establishment Cause for CSFB preceded by Location Update LTE bands mandatory for roaming

CSFB Redirection upon RRCConnectio nRelease with RIM

Idle Mode Mobilit y

Idle Mode Cell Reselection from eUTRA to GSM/GPRS

Idle Mode Mobilit y
Idle Mode Mobilit y

Idle Mode Cell Reselection from eUTRA to UTRA based on subscription/p olicy criteria Idle Mode Cell Reselection from UTRA to eUTRA

Idle Mode Mobilit y

Idle Mode Cell Reselection from GSM/GPRS to eUTRA

The VoLTE capable UE shall support Unstructured Supplementary Service Data (USSD / USSI) using IP multimedia CN Subsystem (IMS) according to 3GPP TS 24.390, Rel-11 and IR.92 v8.0. It is important that all SIP messages (INVITE, INFO & BYE) are supported by the UE in order to enable multiple USSD actions (USSD menu). In case the NW does not support USSD via IMS the UE shall use USSD method selection as described in TS 23.221, Rel-12, June version. Pre-configuration in the UE should be: USSD (USSI) preferred. The UE must use a CSFB indication in Paging Response message as defined in 3GPP TS 44.018
The UE must use an Establishment Cause for CSFB preceded by Location Update as defined in 3GPP TS 44.018
The UE shall also support the following roaming Frequency Bands: Band 17 (UL: 704 ­ 716 MHz, DL: 734 746 MHz) Band 5 (UL: 824 - 849 MHz, DL: 869 894 MHz) Band 4 (UL: 1710 - 1755 MHz, DL: 2110 - 2155 MHz) Redirection upon RRCConnectionRelease RAT Information Management (RIM) according to 3GPP TS 36.401, Rel-9 shall be implemented as a minimum requirement in the LTE device in order to ensure interoperability and minimise call setup delays. The UE shall support Idle Mode Cell Reselection from eUTRA RRC idle state to GSM/GPRS RRC Idle state based on: * subscription/policy criteria * DL radio criteria The UE shall support Idle Mode Cell Reselection from eUTRA RRC Idle state to UTRA RRC Idle state based on: * subscription/policy criteria * DL radio criteria
The UE shall support Idle Mode Cell Reselection from: * UTRA_Idle to eUTRA RRC_Idle * UTRA_CELL_PCH state to eUTRA RRC_IDLE The UE shall support Idle Mode Cell Reselection from GSM_Idle/GPRS Packet_Idle to eUTRA RRC_IDLE. The priority of E-UTRA cells is: * lower than the serving cell

Required for VoLTE Terminals to support legacy voice services. This service is relevant for the VoLTE launch in VF D2. It is essential to support USSD method selection according to TS 23.221, Rel-12, June Version, in case the Voice domain is in IMS and USSD is in CS domain of the NW.
LTE smartphones using CSFB for voice may experience significant delay in MT call setup if this requirement is not satisfied
LTE smartphones using CSFB for voice may experience significant delay in call setup if this requirement is not satisfied Mandatory for LTE terminals to roam internationally. Note that support of these bands must not negatively impact performance on other primary bands.
Essential for LTE terminals offering voice and messaging capability
Essential for LTE/GSM mobility
Essential for LTE/UMTS mobility
Essential for UMTS/LTE mobility
Essential for GSM/LTE mobility

3GPP TS 24.390, Rel-11 3GPP TS 23.221, Rel-12, June version GSMA IR.92 v12.0
3GPP TS 44.018, Rel-11, sections 3.3.2.2, 9.1.25 3GPP TS 44.018, Rel-11, section 9.1.8 N/A
N/A
N/A
N/A
N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service (priority)

* higher than the serving cell

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

General Requirements

Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT

Wide Area Connect ivity

NB-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity

NB-IoT

Idle Mode Mobilit y
Gener al

Idle Mode Cell reselection from GSM/GPRS to E-UTRA Buffer status reporting procedure

Uplink UE transmit antenna selection

The UE shall support Idle Mode Cell Reselection from GSM_Idle/GPRS Packet_Idle to eUTRA RRC_IDLE.
The UE shall support buffer status reporting procedure for suspended bearers.
The UE shall support UE transmit antenna selection, as specified in 3GPP TS 36.213.

Essential for LTE/GSM mobility

N/A

At the moment there is urgency on the usage of OTDOA as Time Sync is needed in the network. Allocation of UL resources only when UE has something to transmit. Avoid allocating resources when UE has nothing to transmit to save network resources. Essential for all LTE terminals in order to allow better performance in uplink

3GPP TS 36.321
3GPP TS 36.213

Power UE Manag measurement ement capabilities

Device mode m suppor t Servic es

BIP session support
SMS traffic IoT

The UE shall support the following UE measurement capabilities as specified in 3GPP TS 36.214: * GSM carrier Received Signal Strength Indicator (RSSI) * UTRA FDD CPICH Ec/No * UTRA FDD carrier Received Signal Strength Indicator (RSSI) * UTRA FDD CPICH Received Signal Code Power (RSCP) In case of non or partial compliance, please state the known limitations in the comment sections. The device SHALL support the BIP session regardless of incoming or outgoing calls, incoming or outgoing MMS, SMS.
The Cat M device shall support the reception and delivery of SMS

Essential for all LTE terminals in order to allow cell reselection and handover decisions.
Required for registration of the Vodafone services.

3GPP TS 36.214
N/A

Locati Radio

The device shall be capable of

Now

on

Measurements measuring up to 8 cell RSRP, Timing

- LTE-IoT

Advance Information and UE Rx-Tx

time difference measurements and

include it in LPP protocol or

Measurement Reports. In both CE

Mode-A and Mode-B.

Locati Radio

The device shall be capable of

Now

on

Measurements measuring up to 8 cell NRSRP, Timing

- NB-IoT

Advance Information and UE Rx-Tx

time difference measurements and

include it in LPP protocol

Locati Idle Mode

The device shall support

Now

on

Measurements measurements described in TCD-

- LTE-IoT

M2M_-REQ-012486 while being in idle

mode as the result of an LPP

information request

Locati Idle Mode

The device shall support

Now

on

Measurements measurements described in TCD-

- NB-IoT

M2M_-REQ-012486 while being in idle

mode as the result of an LPP

information request

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT LTE-IoT

Locati on
Mobilit y
Mobilit y
Mobilit y
Mobilit y
Mobilit y

LTE Positioning Protocol (LPP) - NB-IoT InterRAT cell Handover UE triggered
InterRAT cell Handover network triggered
Connected mode interfrequency mobility
Connected mode intrafrequency mobility
Cell measurements and reporting

The device shall support LPP protocol including Rel-14 enhancements of TS 36.355, section 6.5.3, Enhanced Cell ID Positioning
The device shall support UE Assistance Information (3GPP 36.331, Rel-14, Section 5.6.10 ) to indicate to the network the preference for a configuration that is primarily optimized for power saving (i.e. LTE to Cat-M handover) in both CE Mode A and Mode B. The device shall search for any other IoT technology like LTE in case network triggers it based on the UE measurement reports (RSRP) in both CE Mode A and Mode B The device shall support connected mode inter-freq. mobility between: 1. CE Mode A - CE ModeA 2. CE Mode B- CE Mode B 3. Normal coverage - CE Mode A 4. CE Mode A - CE Mode B The device shall support connected mode intra-freq. mobility between: 1. CE Mode A - CE ModeA 2. CE Mode B- CE Mode B 3. Normal coverage - CE Mode A 4. CE Mode A - CE Mode B The device shall support connected mode serving cell measurements and reporting

Now
Now
Now
Enables handover while maintaining data connection. Particularly important for IoT Devices that are mobile and require permanent data connection Enables handover while maintaining data connection. Particularly important for IoT Devices that are mobile and require permanent data connection Improves network access

Mobilit InterRAT cell

y

reselection

Mobilit y
Mobilit y
Mobilit y

Interfrequency interband cell reselection IoT Interfrequency intraband cell reselection IoT Intrafrequency cell reselection IoT

Batter y Life Extens ion

Idle DRX - LTEIoT

Capaci ty and Scalab ility

High data rate through increased BW

The device shall search in an optimum manner for other IoT technologies like NB-IoT, LTE or 2G in case of Cat-M service/coverage loss or for performance improvement (e.g. throughput, battery) if the device supports more than Cat-M The device shall support inter frequency cell reselection in idle if more than 1 band is supported
The device shall support inter frequency cell reselection in idle while in same band
The device shall support intra frequency cell reselection in idle
The device shall support DRX in idle mode to maximise battery life
The device shall support high data rate through increased PUSCH / PDSCH bandwidth as specified in Rel-14. This category will have maximum bandwidth of 5MHz or 20MHz. Larger TBS + up to 10 HARQ processes.

Now
Improves network access Improves network access Improves network access Should be available now Improves network access

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT NB-IoT

Wide Area Connect ivity

NB-IoT

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT NB-IoT NB-IoT NB-IoT

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT NB-IoT NB-IoT

Wide Area Connect ivity

NB-IoT

Servic es

VoLTE

Support VoLTE coverage for half-

enhancements duplex FDD/TDD system

(Rel-14)

Upgra Firmware des upgrades

Multicast: SC-PTM based multicast design

Improves VoLTE coverage Enables refresh of device firmware

Mobilit Inter-

The device shall support inter

Now

y

frequency

frequency cell reselection in idle if

interband cell more than 1 band is supported

reselection -

IoT

Mobilit Inter-

The device shall support inter

Now

y

frequency

frequency cell reselection in idle while

intraband cell in same band

reselection -

IoT

Batter Idle DRX - NB- The device shall support DRX in idle

y Life IoT

mode to maximise battery life

Extens

ion

Batter y Life Extens ion

Connected DRX - NB-IoT

The device shall support DRX in connected mode to maximise battery life

Timing Fast network The device shall support fast network Now

sync

sync when no cell change after PSM

mode: No SIB measurement, etc.

Uplink Enhanced data The device shall support Rel-14

Now

Trans rate

Enhanced data rate and latency (2

missio

HARQ + TBS. This increases data rate

n

from 25kbps to 85kbps sustained rate)

Mode

Upgra Firmware

The device shall support 3GPP Rel-14 Now

des upgrades

SC-PTM Multicast feature

Capaci ty extens ion

Guard-band + Anchor PRB

Batter y Life Extens ion

Release Assistance Information

Sendin g/rece iving data via

AT commands for sending and receiving data over control plane

The device shall support anchor PRB where 1 PRB is used for PSS-SSS, PBCH and PDCCH and 1 additional PRB for data shared channel (PDSCH/PUSCH)
The NB-IoT Device shall support the Release Assistance In formation feature. After sending the RAI related information, if the device does not receive the anticipated network initiated release, the device may initiate release of the RRC connection by signalling to the eNB. However, if the device uses this option, the device shall listen to its Idle mode DRX occasion for at least 4 DRX occasions after the release (in order to respond to any MME initiated events triggered by the device's RRC connection establishment) The NB-IoT Device shall support the 3GPP AT commands +CSODCP and +CRTDCP.

Improves network access High

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

3GPP TS 24.301, Rel-14

Vodafone Group Products & Service NAS

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT NB-IoT NB-IoT

Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT NB-IoT

Wide Area Connect ivity

NB-IoT

Wide Area Connect ivity

NB-IoT

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT NB-IoT NB-IoT

Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT NB-IoT

IP

UDP

protoc

ol

The NB-IoT Device shall support UDP.

CoAP CoAP over UDP The NB-IoT Device shall support CoAP over UDP

CoAP
AT comm ands

CoAP
AT commands applicable for NB-IoT

The NB-IoT Device shall support CoAP (IETF Constrained Application Protocol) for data transport. The CoAP communication endpoint (e.g. IoT server) can be freely configured on the device. The CoAP layer is open to be used by any service/application. Support of all AT commands applicable for NB-IoT according to 3GPP TS 27.007.

Attach

Attach with PDN connection request

Locati Positioning on

Conge stion contro l

UE back off timer

Access Low access ibility priority UEs

Access Long periodic ibility RAU/TAU
timer

The NB-IoT Device shall support the

attach with PDN connection. The NB-

IoT Device shall be able to read and

handle

"SystemInformationBlockType1-NB".

The device shall support LTE

High

Positioning Protocols (LPP and LPPa) to

be exchanged between the UE/eNB

and the eSMLC, as defined by 3GPP for

NB-IoT in Rel-13 (will be at least RSRP).

LPP also supports A-GNSS signalling /

measurements if the NB-IoT Device has

a GPS

The device shall support UE back-off

timer (timer to monitor the queues for

outstanding requests and the C-SGN

starts to signal the UE to back off when

the queues have reached a certain

threshold.

Device (or SIM) may be configured as

low priority and the RAN can use this to

prohibit access in the case of network

congestion

The device shall support the increase of maximum PLU / PRU timer up to 310 hours.

Access Paging ibility Optimisation
for IoT Traffic

Capaci QoS ty manag ement

IP

IPv4 & IPv6

protoc

ol

The device shall support improved paging optimized for IOT traffic. Paging Optimisation and Paging for Coverage Enhancement capable UEs as specified in TS 36.413, version 13.2.0. The NB_IoT Device shall be compliant with the QoS concepts as described in 3GPP TS 23.401 v11.11.0 [2] section 4.7.
The NB_IoT Device shall be complaint with both IP protocol stacks (IPv4 and IPv6)

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

3GPP TS 27.007 3GPP TS 36.331
N/A
N/A
N/A
N/A
3GPP TS 36.413, version 13.2.0 N/A
N/A

Vodafone Group Products & Service

Wide

NB-IoT

Servic SMS traffic - The NB_IoT Device shall support the Low

N/A

Area

es

IoT

reception and delivery of SMS

Connect

ivity

Wide

NB-IoT

Power Sleep Mode The NB_IoT Device shall support fast High

N/A

Area

saving

return to sleep mode techniques

Connect

ivity

Wide

NB-IoT

Securi Encryption and The device shall support the standards High

N/A

Area

ty

Integrity (user Encryption and Integrity algorithms as

Connect

plane)

part of the basic implementation of NB-

ivity

IoT for the user plane data sent on Data

Radio Bearers

Wide

NB-IoT

Securi Encryption and The device shall support the standards High

N/A

Area

ty

Integrity

Encryption and Integrity algorithms as

Connect

(control plane) part of the basic implementation of NB-

ivity

IoT for the Control Plane channels

Wide

NB-IoT

Optimi ROH

The device shall be compliant with

High

N/A

Area

sed S1 Compression ROHC framework as specified in IETF

Connect

Contro

RFC 4995 and realized in "Data over

ivity

l plane

NAS Convergence Protocol". The

solutio

device will be complaint with the ROHC

n

profiles defined in 36.323 and, at least,

will support the following ROHC packet

types:

- Initialization and Refresh (IR) packet

type;

- IR dynamic part (IR-DYN) packet type;

- Feedback (ACK, NACK, STATIC-NACK)

packet type;

- Compressed (CO) packet type;

Wide

NB-IoT

Optimi Data over NAS The device shall support NB-IoT data High

N/A

Area

sed S1 (Non-IP)

transmission using S1-MME optimised

Connect

Contro

control plane solution (Data over NAS

ivity

l plane

for IP and Non-IP communications, as

solutio

specified in TR 23.720 section 6.18.1.3

n

or the most recent equivalent to be

specified in TS 23.401, version 13.6.0.)

for NB-IoT users. Mandatory solution.

Wide

NB-IoT

Optimi Suspend/Resu The device shall support NB-IoT data High

N/A

Area

sed S1 me mode

transmission using S1-U optimised user

Connect

User

plane solution (Suspend/Resume

ivity

plane

mode state) for NB-IoT users. Optional

solutio

solution

n

Wide

NB-IoT

Batter PSM Mode

The device shall support PSM Mode

N/A

Area

y Life

from 3GPP Rel-12 for NB-IoT Devices to

Connect

Extens

maximise battery life.

ivity

ion

Wide

NB-IoT

Batter Extended DRX The device shall support Extended DRX

N/A

Area

y Life - NB-IoT

feature from 3GPP Rel-13 for NB-IoT

Connect

Extens

devices to maximise battery life.

ivity

ion

Wide

NB-IoT

Capaci Anchor PRB Support for anchor PRB where Primary

N/A

Area

ty

PRB is used for Paging, NPSS-NSSS,

Connect

extens

NPBCH, NPDCCH and NPRACH and

ivity

ion

secondary PRB for data shared

channels (PDSCH/PUSCH). One of the

PRB can go Guard-Band/In-band, the

second PRB can for either Guard-Band

or In-Band

Wide

NB-IoT

Cell Extended Cell Support the CP lenght of 266.7 us for

N/A

Area

Size Size

the PRACH channel configurable by

Connect

the operator for a cell size up to 40Km

ivity

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

NB-IoT

Cell Basic Cell Size The device shall support the basic CP

N/A

Area

Size

length of 66.7 us for the PRACH

Connect

channel

ivity

Wide

NB-IoT

Covera 20 dB

Support of UL modulation in 3GPP

N/A

Area

ge

coverage

(Pi/4-QPSK and Pi/2-BPSK for single

Connect

Extens extension in tone and QPSK for multitone), the

ivity

ion

UL

predefined set of repetitions (from 1 to

128), and low index of Transport Block

table according to 3GPP to reach 20 dB

coverage reaching the 164 dB MCL

Wide

NB-IoT

Covera 20 dB

Support of DL modulations in 3GPP

N/A

Area

ge

coverage

(QPSK, Pi/2-BPSK, Pi/4-QPSK) the

Connect

Extens extension in predefined set of repetitions (from 1 to

ivity

ion

DL

2048), and low index of Transport Block

table according to 3GPP to reach 20 dB

coverage reaching the 164 dB MCL

Wide

NB-IoT

Uplink 3.75 KHz

Support for 3.75 KHz Uplink

High

N/A

Area

Trans single tone

Transmission mode.

Connect

missio

ivity

n

Mode

Wide

NB-IoT

Uplink 15 KHz multi Support for 15 KHz Multitone Uplink High

N/A

Area

Trans tone

Transmission mode. Please specify

Connect

missio

multi-tone configuration supported (3,

ivity

n

6, 12 sub-carriers per IoT Device).

Mode

Wide

NB-IoT

Uplink 15 KHz single Support for 15 KHz Uplink single tone High

N/A

Area

Trans tone

Transmission mode.

Connect

missio

ivity

n

Mode

Wide

NB-IoT

Deplo Standalone

Support for NB-IoT standalone

N/A

Area

yment mode

deployment mode.

Connect

Modes

ivity

Wide

NB-IoT

Deplo Guard-band Support for NB-IoT guard-band

N/A

Area

yment mode

deployment mode (for Bw of 3, 5, 10

Connect

Modes

and 20 MHz)

ivity

Wide

NB-IoT

Deplo DL RB

The device shall support all possible DL

N/A

Area

yment allocation for RB locations for NB-IoT as defined by

Connect

Modes In-band mode 3GPP. Please state what are the DL

ivity

locations supported (8 locations for 10

MHz LTE in B20 band).

Wide

NB-IoT

Deplo UL/DL RB

The device shall support a flexible

N/A

Area

yment allocation for configuration of duplex gap between

Connect

Modes In-band mode uplink and downlink RB's for NB-IoT in

ivity

order to optimise the LTE UL

performance and NB-IoT performance.

Duplex gap for NB-IoT traffic should be

operator configurable. This flexibility is

critical for the UL performance where

the UL transmission use contiguous

PRBs

Wide

NB-IoT

Deplo In-band mode Support for NB-IoT in-band

N/A

Area

yment

deployment mode (with 164 dB MCL).

Connect

Modes

ivity

Wide

NB-IoT

Maxim CAT-NB1

The CAT-NB1 device shall be able to

N/A

Area

um Output power reach up to 20 dBm of maximum

Connect

output II

transmit power (Class 5)

ivity

Power

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

NB-IoT

Maxim CAT-NB1

The CAT-NB1 device shall be able to High

N/A

Area

um Output power reach up to 23 dBm of maximum

Connect

output

transmit power

ivity

Power

Wide

NB-IoT

UE

CAT-NB1

Support for NB-IoT capability Cat-NB1 High

N/A

Area

Categ capability

in the SRAN access node in compliance

Connect

ory

to 3GPP Rel-13 (min. Mar 2017)

ivity

"CAT-

protocol specifications (including

NB1"

single/multitone, 3.75 KHz/15 KHz

for IoT

sub-carrier spacing).

Wide

NB-IoT

3GPP Standard

The NB-IoT Device shall be complaint

N/A

Area

Compl compliancy - to 3GPP Rel-13. The vendor shall state

Connect

iance IoT

the latest version of the 3GPP

ivity

standards the product is compliant to

and list any restriction

Wide

LTE-IoT

Batter PSM

Support for Power Saving Mode feature High

N/A

Area

y Life

from 3GPP Rel-12 for LTE Cat 1, and

Connect

Extens

Cat M devices

ivity

ion

Wide

LTE-IoT

Batter Extended DRX Support for Extended DRX feature from High

N/A

Area

y Life - LTE-IoT

3GPP Rel-13 for LTE Cat 1 and Cat M

Connect

Extens

devices.

ivity

ion

Wide

LTE-IoT

Maxim Cat M Output The Cat M device shall be able to reach High

N/A

Area

um power II

up to 20 dBm of maximum transmit

Connect

output

power (Class 5)

ivity

Power

Wide

LTE-IoT

Maxim Cat M Output The Cat M device shall be able to reach High

N/A

Area

um power

up to 23 dBm of maximum transmit

Connect

output

power

ivity

Power

Wide

LTE-IoT

Covera Cat M

Support for the over 15 dB coverage High

N/A

Area

ge

Deployment enhancements features as specified in

Connect

Extens Mode B

3GPP for cat M IoT Devices with

ivity

ion

coverage

deployment mode B

extension

Wide

LTE-IoT

UE

Half Duplex

Support half-duplex FDD operation for High

N/A

Area

Categ Operation

UE cat M IoT Devices.

Connect

ory M Type

ivity

for IoT

Wide

LTE-IoT

UE

Cat M

Support for 3GPP Rel-13 LTE Cat M

High

N/A

Area

Categ capability

capability in co-existence with all LTE

Connect

ory M

UE categories.

ivity

for IoT

Wide

LTE-IoT

UE

Cat 1

Support for 3GPP Rel-8 LTE Cat 1

High

N/A

Area

Categ capability

capability in co-existence with all LTE

Connect

ory 1

UE categories

ivity

for IoT

Wide

LTE

Area

Connect

ivity

Slicing 4G slicing

The UE shall support any UE application (on Android, iOS, etc.) to be able to use a named APN (e.g. gaming app to use a "low latency APN")

required by 2H19

Wide Area Connect ivity

LTE - Voice and Messaging

VoLTE

VoLTE Interconnect: ICSI service tag

The UE shall support of ICSI service tag: VoLTE UE must populate the ICSI service tag "urn:urn-7:3gppservice.ims.icsi.mmtel " in the SIP Invite to indicate they wish to establish a VoLTE call for originating calls, and in the SIP response (183, 200) to indicate they are ready to accept a VoLTE call for terminating calls.

already

Requirement is aplicable both for 4G

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

and 5G devices when the 5G devices are under Option 3x handling the voice over LTE

Wide Area Connect ivity

LTE - Voice and Messaging

VoLTE

VoLTE roaming: Anonymous Emergency Sessions

The UE shall Support of "anonymous" Emergency Call for outbound VoLTE roamers (S8HR): if the UE receives a SIP 4xx as a response of a IMS Emergency registration attempt, then the UE must perform the procedures defined in subclause 5.1.6.8.2 of 3GPP TS 24.229, Rel-14, as mandate by IR.92 v12. The requirement is aplicable both for 4G and 5G devices when the 5G devices are under Option 3x handling the voice over LTE

By Q2/19

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

2 Carrier Aggre gation (Multi Band) 5 Carrier Aggre gation (Multi Band)
Batter y Life Extens ion Batter y Life Extens ion Latenc y
Latenc y
Latenc y
5G NR

CA_1A-38A DL
CA_1A-3A-7C20A DL
Connected DRX - 5G
Cross slot scheduling
Case 2: PDCCH monitoring
Non-slots: 714 OFDM symbols in Dowlink
Non-slots: 114 OFDM symbols in Uplink
PDCCH case 12

All UE of Cat 6 or higher have to support downlink CA band 1 (2100) + band 38 (2600 TDD) combination: bandwidth B1 (5-20 MHz); B38 (15-20 MHz)
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 7 (2600) contiguous + band20 (800) combination: Bandwidth: B1 (5-20 MHz + B3 (10-20 MHz) + B7 (15-30 MHz)+ B20 (10 MHz) SW support of cDRX
SW support of Cross Slot Scheduling [comment] Large reduction in number of PDSCH to be received
The UE shall support Case 2: PDCCH monitoring periodicity of less than 14 symbols This feature is mandatory without UE capability signalling. The device shall support Time-domain resource allocation - PDSCH mapping type A with 7-14 OFDM symbols (This feature is mandatory without UE capability signalling) The device shall support Time-domain resource allocation - 1-14 OFDM symbols for PUSCH once per slot - Starting symbol, and duration are determined by using the DCI (This feature is mandatory without UE capability signalling) The device will support Case 1: PDCCH monitoring periodicity of 14 or more symbols. Case 1-2: PDCCH monitoring on any span of up to 3 consecutive OFDM symbols of a slot

Essential to ensure sufficient bandwidth for acceptable data rates in Europe. Important to support higher data rates in the Downlink in Europe and AMAP. Available now in Netherlands and in Malta by 2H20. By Q219
By Q420
by Q219
By Q219
By Q219
By Q219 (now for testing)

3GPP TS 36.101
3GPP TS 36.101
3GPP TS 38.306 3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

5G NR 5G NR

PDCCH case 11
Scheduling type A

The device will support Case 1: PDCCH monitoring periodicity of 14 or more symbols. With case 1-1: PDCCH monitoring on up to three OFDM symbols at the beginning of a slot Support of data channel allocation Type A.

By Q219 (now for testing) By Q219 (now for testing)

5G NR Uplink

256QAM for PUSCH

265QAM - 5G

By Q219 (now for testing)

5G NR Uplink 64QAM 64QAM for PUSCH - 5G

By Q219 (now for testing)

5G NR Downlink

256QAM for PDSCH

256QAM - 5G

By Q219 (now for testing)

5G NR Downlink 64QAM - 5G

64QAM for PDSCH

By Q219 (now for testing)

5G NR UE Channel Bandwidth for SCS 30 KHz
5G NR UE Channel Bandwidth for SCS 15KHz
5G NR Diffrent SCS

Support the following UE Channel Bandwidth for SCS of 30kHz: 10 MHz, 15 MHz, 20 MHz, 25 MHz, 40 MHz, 50 MHz, 60 MHz, 80 MHz, 90 MHz, 100 MHz Support the following UE Channel Bandwidth for SCS of 15kHz: 5Mhz, 10 MHz, 15 MHz, 20 MHz, 25 MHz, 40 MHz, 50 MHz
Simultaneous transmission and reception with same or different numerologies in 5G CA

By Q219 (now for testing) By Q219 (now for testing) By Q219 (now for testing)

Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 5 Bands InterB and EN-DC within FR1

DC_20A32A_n78A
DC_1A-7A20A32A_n78A

Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 130 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_8A-20A_n78A combination Min BW: 5+10+20 Max BW: 15+10+100

By 2H19 for UK.

Support of Dual Connectivity between the specified 4 LTE carriers + 1 5G NR carrier up to 180MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 3DL, 2DL or 1DL (+ 5G NR) DC_1A-7A-20A-32A_n78A combination Min BW: 5+15+10+20+20 Max BW: 20+20+10+20+100

UK now. By 2H20 for IT.

3GPP TS 38.306
3GPP TS 38.306 3GPP TS 38.306 3GPP TS 38.306 3GPP TS 38.306 3GPP TS 38.306
3GPP TS 38.1013
3GPP TS 38.1013

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity

LTE
General Requirements

Licens e Assiste d Access

CA_42A-46A

Massiv UDC (uplink

e

data

MIMO compression)

Massiv High power UE

e

(HPUE) - LTE

MIMO

Massiv FDD + TDD UL

e

CA

MIMO

Massiv e MIMO

FDD + TDD DL CA for TM9 CSI with FDD as Pcell

Massiv e MIMO

FDD + TDD DL CA for TM7, TM8 or TM9 SRS with TDD as Pcell

Massiv TM9 Rel-14

e

CSI Class B

MIMO

Massiv TM9 Rel-14

e

CSI Class A

MIMO

Massiv TM9 Rel-14

e

SRS

MIMO

Massiv TM9 Rel-10

e

CSI

MIMO

Massiv TM9 Rel-10

e

SRS

MIMO

Perfor Performance mance of key services

The device shall support License Assisted Access utilising DL carrier aggregation of band 42 (3500) + band 46 (5GHz Unlicense) Bandwidth: B42 (10-20 MHz), B46 (20 MHz) Support for UDC according to 3GPP Rel-15. The vendor shall specify if their solution is 3GPP standard or propietary.
Support for HPUE providing 26dBm (+3dB) according to 3GPP Rel-14 in mainly for B38 and B41-India. Band 40 and Band 42 are nice to have. The supplier to detail which of the bands support. Support for FDD + TDD UL CA when FDD or TDD is Pcell. Specific combos requested defined in separate TCD requirements.
Support for FDD + TDD DL CA for TDD in TM9 CSI when FDD is Pcell. The vendor shall specify the supported band configurations if not band agnostic. Specific band conbination required for FDD+TDD defined in other TCDs Support for FDD + TDD DL CA for TDD in TM7, TM8 or TM9 SRS being TDD set as Pcell. The vendor shall specify the supported band configurations if not band agnostic. Specific combos required for FDD+TDD defined in a different TCDs Support for TM9 Class B based on CSI feedback with 8 ports using for beamformed CSI-RS according to 3GPP Rel-14. Support for up to 4 layers per DL for TM9 Support for TM9 Class A based on CSI feedback calculated from 32-ports non-beamformed CSI-RS according to 3GPP Rel-14. Support for up to 4 layers per DL for TM9 Support for TM9 based on SRS feedback according to 3GPP Rel-14. Support for up to 4 layers per DL for TM9
Support for TM9 based on CSI feedback obtained from 8-ports nonbeamformed CSI-RS according to 3GPP Rel-10. Support for up to 4 layers per DL for TM9 Support for TM9 based on SRS feedback according to 3GPP Rel-10. Support for up to 4 layers per DL for TM9
Key services (e.g. VoLTE and RCS) should be unaffected when a device is connected in EN-DC mode

Important to support higher data rates in DL including the unlicence spectrum. Support requested in Turkey and EU, by 2H19 TR Required to improve throughput in UL Now
Now
Now
Now
By Q219
By Q219
By Q219
Now
Now
Ensure that the addition of new 5G bearers do not impact user experience of key features

3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual Conne ctivity - 2 Bands + SDLSUL InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands + SDLSUL InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands + SUL InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands + SUL InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands + SUL InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands + SUL InterB

DC_8A_SUL_n 75/76_n81
DC_20A_SUL_ n75/76_n82
DC_3A_SUL_n 78A-n82A
DC_3A_SUL_n 78A-n80A
DC_1A_SUL_n 78A-n84A
DC_20A_SUL_ n78A-n82A

Support of Dual connectivity with Supplementary Uplink (SUL) between the specified 1 LTE carriers + 1 5G NR carrier up to 30 MHz, with detailed bandwidth granularity. Min BW: 10+20 Max BW: 10+20
Support of Dual connectivity with Supplementary Uplink (SUL) between the specified 1 LTE carriers + 1 5G NR carrier up to 30 MHz, with detailed bandwidth granularity. Min BW: 10+20 Max BW: 10+20
Support of Dual connectivity with Supplementary Uplink (SUL) between the specified 1 LTE carriers + 1 5G NR carrier up to 115 MHz, with detailed bandwidth granularity. Min BW: 10+20 Max BW: 15+100
Support of Dual connectivity with Supplementary Uplink (SUL) between the specified 1 LTE carriers + 1 5G NR carrier up to 120 MHz, with detailed bandwidth granularity. Min BW: 10+20 Max BW: 20+100
Support of Dual connectivity with Supplementary Uplink (SUL) between the specified 1 LTE carriers + 1 5G NR carrier up to 120 MHz, with detailed bandwidth granularity. Min BW: 10+20 Max BW: 20+100
Support of Dual connectivity with Supplementary Uplink (SUL) between the specified 1 LTE carriers + 1 5G NR carrier up to 110 MHz, with detailed bandwidth granularity. Min BW: 10+20 Max BW: 10+100

By 2H19 for UK. By 2H19 for UK. By 2H19 for UK. By 2H20 for DE and MT. By 2H19 for UK and by 2H20 for DE. By 2H19 for UK and by 2H20 for DE. By 1H19 for UK and by 2H20 for DE.

ongoing in 3GPP
ongoing in 3GPP
3GPP TS 38.1013, Rel15, section 5.5B.4.2
3GPP TS 38.1013, Rel15, section 5.5B.4.2
3GPP TS 38.1013, Rel15, section 5.5B.4.2
Configur ation not in 3GPP 15.2.0

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide Area Connect ivity

LTE-IoT

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity

NB-IoT LTE

Wide

5G

Area

Connect

ivity

and EN-DC within FR1

Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Covera ge Extens ion
4 Carrier Aggre gation (Multi Band)

DC_20A_n8A
Cat M Deployment Mode A coverage extension CA_1A_3A_7A _32A DL

Freque Guard-band ncy edge-to-edge bands separation

Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 25 MHz, with detailed bandwidth granularity. DC_20A_n8A combination Min BW: 10+10 Max BW: 10+15
Support basic deployment mode A operation mode (both level 1 and 2)
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 32 (1400) combination: (min bandwidth 5 MHz + 5 MHz + 15MHz + 20 MHz; max bandwidth 20 MHz + 20MHz + 20MHz + 20MHz) The device shall support edge-to-edge separation of 105 KHz

By 2H19 for UK.
Now Essential to ensure sufficient bandwidth for higher data rates: Italy in 2H19.
By now

3GPP TS 38.1013, Rel15, section 5.5B.4.1
3GPP TS 36.101

Latenc y
Locati on

Supend and Resume mode
MDT - idle mode

Support the RRC Light connection including the S1-U optimised user plane solution (Suspend/Resume mode state)
Support of Logged MDT (Minimization of Drivetests) procedures according to the TS 37.320 Rel-10, chapter 5.1.1. to obtain following information reported by the eNodeB/gNodeB: · time stamp · serving cell ID, including both 4G and 5G NR cells · serving cell measurements (RSRP, RSRQ), including both 4G and 5G NR cells · neighbor cell measurements (RSRP, RSRQ, RSCP, Ec/N0, RxLev,...), including also the 5G NR cells · GNSS location (Standalone UE GPS) according to the TS 36.331 Release if available by the UE when taking the measurement · Timing Advance · If there is any parameter not reported in the MDT loggs please specify it. · Vendor should specify if there is any limit in logging time. · If there is any limit on number of users please specify it. This information will be available to external tracing tools to estimate the location of the UEs

3GPP Rel-13 will improve the latency in control plane. Latency is one of the key factors to enhance the User Experience, and now the current RTT measurements are between 20 and 40 ms By Q219 (now for testing)

3GPP TS 36.331 Rel-13

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Locati on

MDT connected mode

Latenc Light Control

y

Plane

Connection

Latenc Fast HARQ

y

process

5G NR DFTS-OFDM

Support of MDT (Minimization of Drivetests) in RRC_ connected mode according to the TS 37.320 Rel-10, chapter 5.2.1.3. to obtain following information reported by the eNodeB/gNodeB: · time stamp · serving cell ID, including both 4G and 5G NR cells · serving cell measurements (RSRP, RSRQ), including both 4G and 5G NR cells · neighbor cell measurements (RSRP, RSRQ, RSCP, Ec/N0, RxLev,...), including also the 5G NR cells · GNSS location (Standalone UE GPS) according to the TS 36.331 Release if available by the UE when taking the measurement · Timing Advance

By Q219 (now for testing)

· If there is any parameter not reported by MDT please specify it. · If there is any limit on number of users please specify it. This information will be available to external tracing tools to estimate the location of the UEs The device shall support the RRC Light connection including the S1-U optimised user plane solution (Suspend/Resume mode state) for the NSA Dual Connectivity The device shall support operation of fast ACK/NACK and fast scheduling to reduce the latency. Max number of HARQ processes=16, Configurable HARQ DL-UL timing offset, n+ "configurable parameter" per UE The device shall support the waveform DFTS-OFDM with the different numerology in UL

By Q219 (now for testing) By Q219 (now for testing) By Q219 (now for testing)

5G NR CP-OFDM

The device shall support the waveform CP-OFDM with the different numerology in UL and DL

By Q219 (now for testing)

5G NR 5G NR

Subcarrier Spacing 60, 120 and 240 KHz
Subcarrier Spacing 30 KHz

The device shall support 60, 120 and 240 KHz of SCS for mmWave bands

By Q219 (now for testing)

The device shall support 30 KHz of SCS By Q219 (now for testing) for band n78

5G NR Subcarrier Spacing 15 and 30 KHz

The device shall support 15 and 30 KHz By Q219 (now for testing) of SCS for sub-1 GHz bands (e.g. 700 MHz band)

5G NR

5G NR support as specified in 3GPP Rel-15

Support for 5G NR as per 3GPP Rel-15, Version 15.3.x or later, specification. devices shall support all mandatory 5G NR capabilities to allow full interoperability with Rel-15 5G NR RAN Networks

By Q219 (now for testing)

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

VoLTE SRVCC Support

The device will support the current

By Q219 (now for testing)

features SRVCC to 2G/3G when there is

a 5G NR in NSA link setup

VoLTE
QoS:Q CI
RAN Sharin g
RAN Sharin g
Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1

VoLTE Service Legacy QCI 5G Mobility shared and non-shared RAN MOCN - 5G DC_8A_n78A
DC_28A_n78A
DC_1A_n78A
DC_7A_n78A

The device will support the current VoLTE service including all the 4G features enhancing the performance of VoLTE when there is a 5G NR NSA established The device will support the legacy 4G QoS Class Identifier (QCI) with the current 4G QoS parameters including the Guaranteed Bit Rate (GBR).
As per 3GPP TR 38.801 section 5.5, support of mobility between nonshared RAN and shared RAN
As per 3GPP TR 38.801 section 5.5, Mulit-Operator Core Network. Support of Shared RAN on shared spectrum. Up to 4 operators, sending multiple PLMNIds "Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 120 MHz, with detailed bandwidth granularity. DC_8A_n78A combination Min BW: 5+20 Max BW: 15+100"
Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 115 MHz, with detailed bandwidth granularity. DC_28A_n78A combination Min BW: 10+20 Max BW: 15+100
Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 120 MHz, with detailed bandwidth granularity. DC_1A_n78A combination Min BW: 5+20 Max BW: 20+100
Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 120 MHz, with detailed bandwidth granularity. DC_7A_n78A combination Min BW: 15+20 Max BW: 20+100

By Q219 (now for testing) By Q219 (now for testing) By Q219 (now for testing) By Q219 (now for testing) By 2H19 for UK and DE. By 2H20 for NZ.
By 2H19 for NZ.
By now for DE and IT. By 2H19 for NZ and UK. By 2H20 for ES.
By now for ES, DE, IE and IT. By 2H19 for UK and NZ.

3GPP TS 38.1013, Rel15, section 5.5B.4.1
3GPP TS 38.1013, Rel15, section 5.5B.4.1
3GPP TS 38.1013, Rel15, section 5.5B.4.1
3GPP TS 38.1013, Rel15, section 5.5B.4.1

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1

DC_3A_n78A
DC_20A_n78A
DC_20_n28A
DC_8A20A_n78A
DC_1A8A_n78A
DC_7A28A_n78A

Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 120 MHz, with detailed bandwidth granularity. DC_3A_n78A combination Min BW: 5+20 Max BW: 20+100
Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 110 MHz, with detailed bandwidth granularity. DC_20A_n78A combination Min BW: 10+20 Max BW: 10+100
Support of Dual connectivity between the specified 1 LTE carriers + 1 5G NR carrier up to 20 MHz, with detailed bandwidth granularity. DC_20_n28A combination Min BW: 10+10 Max BW: 10+10
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 125 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_8A-20A_n78A combination Min BW: 5+10+20 Max BW: 15+10+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_1A-8A_n78A combination Min BW: 5+5+20 Max BW: 20+15+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_7A-28A_n78A combination Min BW: 15+10+20 Max BW: 20+15+100

By now for ES, DE and IT. By 2H19 for UK, IE and NZ. By 2H20 for MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.1

By now for ES, DE and IT. By 2H19 for UK and IE.

3GPP TS 38.1013, Rel15, section 5.5B.4.1

By 2H19 for DE. By 2H20 for UK.

3GPP TS 38.1013, Rel15, section 5.5B.4.1

By 2H19 for UK and DE. By 2H20 for ES.

Configur ation not in 3GPP 15.2.0

By 2H19 for UK and DE. By 2H20 for ES and NZ.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

By 2H19 for NZ.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1

DC_3A28A_n78A
DC_20A38A_n78A
DC_3A38A_n78A
DC_1A_7A_n7 8A
DC_1A3A_n78A
DC_1A20A_n78A

Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_3A-28A_n78A combination Min BW: 5+10+20 Max BW: 20+15+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 130MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_20A-38A_n78A combination Min BW: 10+10+20 Max BW: 10+20+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 140MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_3A-38A_n78A Min BW: 5+10+20 Max BW: 20+20+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 140 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_1A_7A_n78A combination Min BW: 5+15+20 Max BW: 20+20+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 140 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_1A-3A_n78A combination Min BW: 5+3+20 Max BW: 20+20+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 130MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_1A-20A_n78A combination Min BW: 5+10+20 Max BW: 20+10+100

By 2H19 for NZ. By 2H20 for MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

By 2H19 for UK and DE.

Configur ation not in 3GPP 15.2.0

By 2H19 for DE

3GPP TS 38.1013, Rel15, section 5.5B.4.2

By now for DE and IT. By 2H19 for NZ and UK. By 2H20 for ES.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

In plan for EU and AMAP, IN By now for IT and DE. By 2H19 for UK and NZ. By 2H20 for ES and MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

EU and AMAP By now for DE and IT. By 2H19 for UK. By 2H20 for ES.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1

DC_3C_n78A
DC_3A7A_n78A
DC_3A20A_n78A
DC_7A20A_n78A
DC_1A-8A20A_n78A
DC_1A-3A28A_n78A

Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 125 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_3C_n78A contiguous Min BW: 20+5+20 Max BW: 20+15+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 140MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_3A-7A_n78A coombination Min BW: 5+15+20 Max BW: 20+20+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 130MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_3A-20A_n78A Min BW: 5+10+20 Max BW: 20+10+100
Support of Dual connectivity between the specified 2 LTE carriers + 1 5G NR carrier up to 130MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 1DL (+ 5G NR) DC_7A-20A_n78A combination Min BW: 15+10+20 Max BW: 20+10+100
Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 145 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_1A-8A-20A_n78A Min BW: 5+5+10+20 Max BW: 20+15+10+100
Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 155 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_1A-3A-28A_n78A combination Min BW: 5+5+10+20 Max BW: 20+20+15+100

By 2H19 for DE, IE and NZ.

3GPP TS 38.1013, Rel15, section 5.5B.4.1

Massively rollout in EU and AMAP By now for ES, DE and IT. By 2H19 for IE, UK and NZ. By 2H20 for MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

EU and AMAP By now for ES, DE and IT. By 2H19 for UK and IE. By 2H20 for MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

EU and AMAP By now for ES, DE and IT. By 2H19 for UK and IE.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

By 2H19 for DE and UK. By 2H20 for ES.

Configur ation not in 3GPP 15.2.0

By 2H20 for NZ.

3GPP TS 38.1013, Rel15, section 5.5B.4.3

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1

DC_3A-7A28A_n78A
DC_3C7A_n78A
DC_3C20A_n78A
DC_1A-3A7A_n78A
DC_1A-3A20A_n78A
DC_1A-7A20A_n78A

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 155 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_3A-7A-28A_n78A combination Min BW: 5+15+10+20 Max BW: 20+20+15+100

By 2H19 for NZ. By 2H20 for MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.3

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 150 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_3C-7A_n78A contiguous Min BW: 20+5+15+20 Max BW: 20+10+20+100

By 2H19 for De and NZ.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 140 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_3C-20A_n78A contiguous Min BW: 20+5+10+20 Max BW: 20+10+10+100

By 2H19 for DE and IE.

3GPP TS 38.1013, Rel15, section 5.5B.4.2

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 150 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_1A-3A-7A_n78A combination Min BW: 5+5+15+20 Max BW: 20+20+10+100

EU By now for DE. By 2H19 for UK, IT and NZ. By 2H20 for ES and MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.3

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 150 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_1A-3A-20A_n78A combination Min BW: 5+5+10+20 Max BW: 20+20+10+100

EU By now for DE and IT. By 2H19 for UK. By 2H20 for ES and MT.

3GPP TS 38.1013, Rel15, section 5.5B.4.3

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 150 MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_1A-7A-20A_n78A combination Min BW: 5+15+10+20 Max BW: 20+20+10+100

EU By now IT and DE. By 2H19 for UK. By 2H20 for ES.

3GPP TS 38.1013, Rel15, section 5.5B.4.3

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 5 Bands InterB and EN-DC within FR1 4 Carrier Aggre gation (Multi Band)
4 Carrier Aggre gation (Multi Band)
4 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)

DC_3A-7A20A_n78A
DC_3A-7A20A32A_n78A
CA_3A-7A-8A20A DL
CA_1A-3A-7A8A DL
CA_1A-3A-8A20A DL
CA_3A-8A-20A DL
CA_1A-8A-20A DL
CA_1A-3A-8A DL

Support of Dual connectivity between the specified 3 LTE carriers + 1 5G NR carrier up to 150MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 2DL or 1DL (+ 5G NR) DC_3A-7A-20A_n78A combination Min BW: 5+15+10+20 Max BW: 20+20+10+100
Support of Dual Connectivity between the specified 4 LTE carriers + 1 5G NR carrier up to 180MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 3DL, 2DL or 1DL (+ 5G NR) DC_3A-7A-20A-32A_n78A combination Min BW: 5+15+10+20+20 Max BW: 20+20+10+20+100
All UEs of Cat 11 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 8 (900) + band 20 (800) combination: (min bandwidth 5 MHz + 15 MHz + 5MHz + 10 MHz; max bandwidth 20 MHz + 20MHz + 15MHz + 10MHz) All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 8 (900) combination: (min bandwidth 5 MHz + 5 MHz + 15MHz + 5 MHz; max bandwidth 20 MHz + 20MHz + 20MHz + 15MHz) All UEs of Cat11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 8 (900) + band 20 (800) combination: (min bandwidth 5MHz + 5 MHz + 5MHz + 10MHz; max bandwidth 20 MHz + 10MHz + 10MHz + 10 Mhz) All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 8 (900) + band 20 (800) combination: min bandwidth 5 MHz + 5 MHz + 10 MHz; max bandwidth 20 MHz + 15 MHz + 10 MHz All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 8 (900) + band 20 (800) combination: min bandwidth 5 MHz + 5 MHz + 10 MHz; max bandwidth 20 MHz + 15 MHz + 10 MHz All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 8 (900) combination: (min bandwidth 5MHz + 5MHz + 5MHz; max bandwidth 20MHz + 20MHz +

EU By now ES, DE and IT. By 2H19 for UK. By 2H20 for AL.
IT now.By 1H19 for UK. By 2H20 for MT.
Essential to ensure sufficient bandwidth for higher data rates. Available now in Turkey.
Essential to ensure sufficient bandwidth for higher data rates. In Greece, New Zeland and Germany by 2H19.
Essential to ensure sufficient bandwidth for higher data rates. In Turkey, Spain, Greece, Netherlands and Germany by 2H19.
Essential to ensure sufficient bandwidth for acceptable data rates: Available now in Turkey and Greece.
Essential to ensure sufficient bandwidth for acceptable data rates.
Essential to ensure sufficient bandwidth for acceptable data rates. In Turkey, South Africa and Egypt available now.

3GPP TS 38.1013, Rel15, section 5.5B.4.3
Configur ation not in 3GPP 15.2.0
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

15MHz)

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT LTE-IoT LTE-IoT NB-IoT NB-IoT General Requirements

2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) Freque ncy bands

CA_7C DL CA_8A-20A DL CA_1A-8A DL CA_3A-8A DL LTE-IoT Band 28

All UE of Cat 6 or higher have to support downlink CA band 7 (2600) + band 7 (2600) combination, using continuous bands: (min bandwidth 5 MHz + 5 MHz; max bandwidth 20MHz + 20 MHz) All UEs of Cat 6 or higher have to support downlink CA band 8 (900) + band 20 (800) combination: (min bandwidth 5 MHz + 5 MHz; max bandwidth 20 MHz + 20 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 1 (2100) + band 8 (900) combination: (min bandwidth 5 MHz + 5 MHz; max bandwidth 20 MHz + 20 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 8 (900) combination: (min bandwidth 5 MHz + 5 MHz; max bandwidth 20 MHz + 20 MHz)
The device shall support B28 frequency band

Freque LTE-IoT Band 3 The device shall support B3 frequency

ncy

band

bands

Freque LTE-IoT Band 8 The device shall support B8 frequency

ncy

band

bands

Freque LTE-IoT Band ncy 20 bands

The device shall support B20 frequency band

Freque NB-IOT Bands ncy 28 and 3 bands

The device shall support B28 (NZ) and B3 (NZ,IN) frequency band

Freque NB-IoT Bands ncy 20 and 8 bands

The device shall support B20 and B8 frequency bands

Roami Data

ng

consumption

while roaming

The device shall not consume any data while roaming prior to validation of the user data roaming setting

Essential to ensure sufficient bandwidth for acceptable data rates. In Netherlands and Ireland available now. Essential to ensure sufficient bandwidth for acceptable data rates.
Essential to ensure sufficient bandwidth for acceptable data rates.
Essential to ensure sufficient bandwidth for acceptable data rates.
Mainly for NZ
Mainly for IN, NZ
Mainly for NZ, IN
This is required as some UEs have been found to consume a small amount of data while roaming (and thus triggering the roaming charge) even though the user interface has data roaming disabled. In some instances the UE software establishes a data connection before the UI setting has been read by the firmware.

3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101, Rel-13 3GPP TS 36.101, Rel-13 3GPP TS 36.101, Rel-13 3GPP TS 36.101, Rel-13
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Licens e Assiste d Access

CA_7A-46C

Licens e Assiste d Access

CA_3A-46A

Latenc y

L2 Improvements of Rel-14 (Fast UL access)

Massiv TM8 e MIMO

The device shall support License Assisted Access utilising DL carrier aggregation of band 7 (2600) + band 46 (5GHz Unlicence)+ band 46 (5GHz Unlicence) (min bandwidth 15 MHz + 20MHz +20MHz; max bandwidth 20MHz + 20MHz +20MHz) The device shall support License Assisted Access utilising DL carrier aggregation of band 3 (1800) + band 46 (5GHz Unlicenced) (min bandwidth 3 MHz + 20MHz; max bandwidth 20MHz + 30MHz) This included the L2 improvements from Rel-14. Semi Persistent scheduling (SPS) with a periodicity reduction up to 1ms (Removes the scheduling request to get UL transmission) Skip padding transmission in case there is no data to transmit after the grant allocation.
The UE shall support Transmission Mode 8 (TM8). Support for up to 2 layers per in DL for TM8.

Important to support higher data rates in DL including the unlicence spectrum. Support requested in Turkey
Important to support higher data rates in DL including the unlicence spectrum. Support requested in IN and South Africa
Requested for information. 3GPP Rel-14 will improve the latency, and it is quite important the industry is adopting them tentative by 2H17 as earliest Latency is one of the key factors to enhance the User Experience, and now the current RTT measurements are between 20 and 40 ms ·Under investigation the current breakdown of the latency including the UE processing time Now

3GPP TS 36.101
3GPP TS 36.101 N/A
3GPP TS 36.213

2 Carrier Aggre gation (Multi Band) 4 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
MIMO

CA_1A-7A DL
CA_1A-3A-7A28A DL
CA_1A-20A32A DL
CA_1A-3A-7A DL
DL MU MIMO

All UEs of Cat 6 or higher have to support downlink CA band 1 (2100) + band 7 (2600) combination: (min bandwidth 5 MHz + 20 MHz; max bandwidth 15 MHz + 20MHz)
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 28 (700) combination: (min bandwidth 5 MHz + 5 MHz + 15MHz + 15 MHz; max bandwidth 15 MHz + 20MHz + 15MHz + 15MHz) All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 20 (800) + band 32 (1400) combination: (min bandwidth 5 MHz + 10MHz + 20 MHz; max bandwidth 15 MHz + 10MHz + 20MHz) All UEs of Cat 6 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) combination: (min bandwidth 5 MHz + 5 MHz + 20 MHz; max bandwidth 15 MHz + 20MHz + 20MHz) E-UTRAN shall support the following downlink multi-user MIMO modes: 1) 2x2 (2 users using same PRB´s). 2) 4x2 (2 users using same PRB´s). Device to support this requirement with TM9 better than TM5

Important to support higher data rates in the Downlink.

3GPP TS 36.101

Important to support higher data rates in the Downlink. Available now in NZ and in Germany by 2H19.

3GPP TS 36.101

Important to support higher data rates in the Downlink. In UK available now. In Greece and Italy by 2H20.

3GPP TS 36.101 Rel-15

Important to support higher data rates in the Downlink. In UK and Portugal available now.

3GPP TS 36.101

Now

N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

GSM

Area

Connect

ivity

3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) Carrier Aggre gation
5 Carrier Aggre gation (Multi Band)
4 Carrier Aggre gation (Multi band)
3 Carrier Aggre gation (Multi Band) VAMO S

CA_3C-7A DL
CA_3C-32A DL
CA_3C-20A DL
CA_3A-32A DL
CA_20A-32A DL
Dual Connectivity option 3C support
CA_3C-7A20A-32A DL
CA_3C-7A-20A DL
CA_3A-20A32A DL
VAMOS II

All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) combination: Bandwidth: (20 MHz -lower carrier + 5 MHz -higher carrier) + 20 MHz
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 32 (1400) combination: Bandwidth: (20 MHz -lower carrier + 5 MHz -higher carrier) + 20 MHz
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 20 (800) combination: Bandwidth: (20 MHz -lower carrier + 5 MHz -higher carrier) + 10 MHz
All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 32 (1400): (min bandwidth 10 MHz + 20 MHz; max bandwidth 20 MHz + 20 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 20 (800) + band 32 (1400): (min bandwidth 10 MHz + 20 MHz; max bandwidth 10 MHz + 20 MHz)
Support for 3GPP Rel-12 Dual Connectivity according to 3GPP option 3C (RAN PDCP level split - independent RLC) across cells belonging to non colocated eNB's. Feature shall be able to operate with latency tolerance up to least 5 ms one way delay.
Starting 2017/18 all UEs of Cat 11 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 20 (800) + band 32 (1400) combination: Bandwidth: (20 MHz -lower carrier + 5 MHz -higher carrier) + 20 MHz + 10 MHz + 20 MHz All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 20 (800) combination: Bandwidth: (20 MHz -lower carrier + 5 MHz -higher carrier) + 20 MHz + 10 MHz All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 20 (800) + band 32 (1400) combination: Bandwidth: 20 MHz + 10 MHz + 20 MHz
The device shall support VAMOS 2 as specified in 3GPP TS 45.005.

Important to support higher data rates in the Downlink. In New Zeland and Ireland available now. In Romania and Germany by 2H19.
Support for deployment starting by 2H19, in VF DE
Support for large scale deployment of 1800 in Europe.
Important to support higher data rates in the Downlink in Europe. In Greece by 2H20.
Important to support higher data rates in the Downlink in Europe. In UK available now. In Greece by 2H20.
Important requirement for D-RAN scenarios where X2 latency are not met or time sync not available. Targeted for single vendor scenarios. More efficient from RAN performance but costly in Tx due to tromboning effect. Expected to implement since 1H17 Important to support higher data rates in the Downlink in Europe and AMAP
Important to support higher data rates in the Downlink. In Germany by 2H19.
Important to support higher data rates in the Downlink. In Greece and Italy by 2H20.
Lack of support will reduce ability of Vodafone operating companies to make efficient use of available network bandwidth for 2G voice. This is particularly important for 2G devices in emerging markets such as India where there is massive growth in voice traffic with limited network resource

N/A
N/A
3GPP TS 36.101 Rel-14 N/A
N/A
3GPP TS.36.32 3, TS 36.300 Rel-12 N/A
N/A
3GPP TS 36.101, Rel-14 N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Locati OTDOA on

Positioning method based on Observed Time Difference of Arrival, reporting to the eNB the reference signal time difference (RSTD) measurements. The UE will support the Positioning Reference Signals (PRS) to improve the accuracy and performance of the OTDOA method.

Requested for information. It could allow the provision of more accurate location cell based information, however currently this is optional as the major focus is on location based on MDT and RPS.
When using Observed Time Difference Of Arrival (OTDOA) positioning the network sends the device multiple copies of the same message from different base stations so that the device can make measurements which allow its position to be worked out more accurately than just using a single cell-ID or Enhanced Cell-ID. The network tells the device what to listen for where, and the device sends back it's measurements to the network.

3GPP TS 36.211

Locati on
SON SON SON

MDT connected mode (GPS)
MDT improvements - multiple PLMN
MDT improvements - logging of QoS MDT improvements - accessibility report

Support of MDT (Minimization of Drivetests) in RRC_ connected mode according to the 3GPP TS 37.320, chapter 5.2.1.3. to obtain all information: · time stamp · serving cell ID · serving cell measurements (RSRP, RSRQ) · neighbor cell measurements (RSRP, RSRQ, RSCP, Ec/N0, RxLev,...) · GNSS location (Standalone UE GPS) according to the TS 36.331 Release if available by the UE when taking the measurement · Timing Advance according to TS 36.214 Release. The vendor should specify the feature required for each parameter. If there is any parameter not available on the chipset please specify it. MDT (Minimization of Drivetests) PLMN indicating the PLMNs where measurement collection and log reporting is allowed. It is either the Management Based MDT PLMN List or the Signalling Based MDT PLMN List, depending on how the Logged MDT task was initiated. As defined in 3GPP TS 37.320. MDT (Minimization of Drivetests) functionality to assess the QoS experience for a specific UE together with location information. Minimisation of Drive tests as defined in 3GPP TS 37.320. The device shall create logs of failed RRC connection establishments for LTE and UMTS, i.e. a log is created when the RRC connection establishment procedure fails. The UE logs failed RRC connection establishments without the need for prior configuration by the network. As defined in 3GPP TS 37.320, Minimization of Drivetests

GPS info is today available to the end user in most smartphones (provided the UE position allows to receive the GPS signal), but it's not available to the Radio Access Layer for any NW optimization based on UE location. GPS accuracy is much better than the one obtained using other methods like OTDOA and its evolutions

3GPP TS 37.320

Essential for all LTE devices - allows 3GPP TS

networks to self organise

37.320

Essential for all LTE devices - allows 3GPP TS

networks to self organise

37.320

Essential for all LTE devices - allows 3GPP TS

networks to self organise

37.320

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Advan ced Receiv er Techn ologie s Hetero geneo us Netwo rks
Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation

2 Way RX Div in idle mode
FeICIC
Dual Connectivity for UE
CA_1A-3A-28A DL
CA_1A-7A-20A DL
CA_7A-20A38A DL
CA_3A-7A-20A DL CA_3A-38A DL
CA_1A-20A DL

The device shall implement R/X Diversity IN IDLE MODE to improve performance relative to a standard RAKE receiver
Essential for all LTE devicess - allows to efficiently deploy different cell layers within the network. Device base needs to grow in order to take full advantage of the feature as efficiency benefit is relative to number of supporting devices 3GPP Rel-12 feature allows CA aggregation for cells that are not colocated.
Needed to specify the option supported: - Option 3C async mode. - Synchronisation mode.
Band Combination priorities: -800MHz + 1800MHz -800MHz + 2600MH -1800MHz + 2600MHz -800MHz + 1800MHz + 2600MHz All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 28 (700 APAC) combination: min bandwidth 5 MHz + 5 MHz + 10 MHz; max bandwidth 20 MHz + 20 MHz + 10 MHz All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 20 (800) combination: min bandwidth 5 MHz + 10 MHz + 20 MHz; max bandwidth 20 MHz + 10 MHz + 20 MHz All UEs of Cat 9 or higher have to support downlink CA band 7 (2600) + band 20 (800) + band 38 (2600TDD) combination: min bandwidth 10 MHz + 5 MHz + 20 MHz; max bandwidth 20 MHz + 10 MHz + 20 MHz All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 20 (800) combination: Min bandwidth 5 + 20 + 10 Max bandwidth 20 + 20 + 10 All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 38 (2600 TDD) combination: (min bandwidth 5 MHz + 20 MHz; max bandwidth 20 MHz + 20 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 1 (2100) + band 20 (800) combination: (min bandwidth 5 MHz + 10 MHz;

Improved performance/coverage in idle mode
This feature is needed in order to create in 4G Macro to Small Cell carrier aggregation when no ideal backhauling is available for the Small Cells, or for having LTE multi-flow feature for cell edge, allowing the combination of 1 carrier from site 1 and another carrier from site 2. DL and UL aggregation capabilities are standardised for DC, main focus of VF is the DL.
Important to support higher data rates in the Downlink in New Zealand and Europe.
Important to support higher data rates in the Downlink in Europe.
All UEs Cat 9 or higher, or Cat6 supporting 3CA have also to support this combination. Important to support higher data rates in the Downlink in Europe.
All UEs Cat 9 or higher, or Cat6 supporting 3CA have also to support this combination.
Important to support higher data rates in the Downlink in Europe.
Important to support higher data rates in the Downlink in Europe.

N/A
3GPP TS 36.300 and 3GPP TS 36.331 3GPP TS 36.300, Rel-12
3GPP TS 36.101
3GPP TS 36.101
Not yet in TS 36.101 (Status Aug15)
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
(Multi Band)

max bandwidth 20 MHz + 10 MHz)

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE LTE LTE LTE LTE
LTE
LTE
LTE - Voice and Messaging General Requirements

2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) Licens e Assiste d Access

CA_7A-28A DL
CA_3A-28A DL
CA_3A-3A DL
LAA Coexistence with WiFi

Licens e Assiste d Access

LAA Listen Before Talk (LBT)

Licens e Assiste d Access

LAA bands

Licens e Assiste d Access

LAA standards

SMS via IMS

Simultaneous support of SMSoIP and SMS over SGs

NW Releas e Cause s

SM Cause Codes support for back-off timer (Rel-10)

All UEs of Cat 6 or higher have to support downlink CA band 7 (2600) + band 28 (700 APAC) combination: (min bandwidth 15 MHz + 15 MHz; max bandwidth 15 MHz + 15 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 28 (700 APAC) combination: (min bandwidth 5 MHz + 15 MHz; max bandwidth 20 MHz + 15 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band3 (1800) combination, using noncontinuous bands: (min bandwidth 5 MHz + 5 MHz; max bandwidth 10 MHz + 15 MHz) The UE shall support both WiFi and License Assisted Access and should implement measures to ensure that these technologies do not impair each other
The UE shall support Listen Before Talk, Dynamic Frequency Selection and Transmit Power Control where this is a regulatory requirement
The UE shall support License Assisted Access on the following frequency ranges: 5150MHz to 5350MHz 5470MHz to 5725MHz 5725MHz to 5875MHz 5825MHz to 5875MHz The UE shall support a License Assisted Access solution compliant with 3GPP Rel-13 release.
Depending on a network configuration, the UE shall be able to support SMSoSGs or SMSoIP; also mixed scenario are possible like originated SMSoIP and terminated SMSoSGs (For further details please refer to VVS) The UE shall be able to understand the SM cause codes #26 "insufficient NW resources" and #27 "unknown/undefined APN" according to 3GPP TS 24.008, Rel-10. These cause codes are necessary to support the new back-off functionality defined in 3GPP TS 23.060, Rel-10.

Important to support higher data rates in the Downlink. In New Zealand available now. In Germany by 2H19. In Ireland by 2H20.
Important to support higher data rates in the Downlink.
Important to support higher data rates in the Downlink. In Romania available now.
Device must be able to support WiFi without interference with License Assisted Access technology. Device support of License Assisted Access must also not impair performance of WiFi Failure to implement Listen Before Talk will result in regulatory noncompliance in some markets and will potentially impact other transmission technologies utilising the same unlicensed frequencies (e.g. WiFi) Frequency band support and power levels are market specific. See reference document for details.
License Assisted Access LTE-U is to be launched in key Vodafone target markets in order to enhance LTE capacity where the licensed bands are limited and also to provide enhanced indoor LTE coverage. Initial priority markets are India, South Africa and Netherlands. Possible extension of deployment to other markets. Important for VoLTE services
The support of these cause codes is essential in order to steer the PDP context activation signalling of the terminals e.g. after downtime and recovery of customer servers to avoid signalling load.

3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
ETSI EN 301 893
3GPP TS 36.101
3GPP TS 36.101
VVS
3GPP TS 24.008 Rel-10, TS 23.060, Rel-10

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Gener LTE Band 28 al

Gener al

Blind reselection to LTE after CSFB

Idle Mode Mobilit y

Packet Measurement Order

MIMO UL MIMO

MIMO MIMO 4x4 with CA
MIMO MIMO 4x2

MIMO MIMO 2x2

RAN MOCN - LTE Sharin g

2 Carrier Aggre gation (Multi

CA_1A-3A DL

The UE shall support the following additional Frequency Bands: Band 28 (lower duplexer, i.e. (uplink 703-733 MHz and downlink 758-788 MHz) - While supporting the part of band 28 defined above, following out of band emission limit shall be met: "The mobile terminal out of band emission limit into the 470-694 MHz band is -42dBm/(8 MHz) for 10 MHz LTE bandwidth" The LTE UE shall support "blind" redirection to LTE after CSFB to GSM/GERAN. In some networks some 2G cells are not able to configure LTE neighboring cells. To prevent the EU sticking in 2G after CSFB the UE shall preform blind redirection to the last known LTE Band / Frequency after any CS or Supplementary Service call release or periodic LAU on GERAN. The terminals must support the TS 44.060 Packet Measurement Order (PMO) message as well as Priority based Cell Reselection. (To support Subscriber Profile ID (SPID) for RAT/Frequency in BSC) Single User MIMO (Cat 7 - 100 Mbps)
Support MIMO 4x4 closed loop spatial multiplexing with CA. In that case MIMO 4x4 should be supported in two frequency layers.
Priority Band for 4x4: B3, B7. Lower priority: B1, B38. 4x2: closed loop spatial multiplexing
2x2: Closed loop spatial multiplexing 2x2. 2x2: Open loop spatial multiplexing 2x2.
The UE shall support Multi-Operator Core Network functionality for LTE 800, LTE 1800 and LTE 2600.
All UEs of Cat 6 or higher have to support downlink CA band 1 (2100) + band 3 (1800) combination: (min bandwidth 5 MHz + 5 MHz; max bandwidth 20 MHz + 20 MHz)

Essential for LTE devices as these bands are in use in Vodafone Operating Companies. The out of band emission limit (optional) will be beneficial to harmonise the out of band requirements for 700 MHz mobile terminals between Europe and other regions.
This workaround is necessary to prevent that the user sticks to 2G after CSFB although 4G cells are available but not configurable as neighbouring cell in the "old" GERAN cell.
Important to redirect the UE to the proper frequency / RAT.
Now
Now
Now
Now
MOCN (Multi Operator Core Network) is a RAN Sharing feature in theory mandatory in LTE (and band agnostic). Essential now that Radio Access network sharing is becoming increasingly important. Important to support higher data rates in the Downlink in Europe and AMAP OpCo.

3GPP TS 36.101
N/A
3GPP TS 44.060
3GPP TS 36.306, and tables 4.1.1, 4.1.2 and 4.1.3 3GPP TS 36.306, tables 4.1-1, 4.1-2 and 4.13 3GPP TS 36.306, tables 4.1-1, 4.1-2 and 4.13 3GPP TS 36.306, tables 4.1-1, 4.1-2 and 4.13 3GPP TS 23.251, 3GPP TS 36.300
3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service Band)

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

UMTS

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

UMTS

Wide Area Connect ivity

UMTS

Wide Area Connect ivity

UMTS

Wide Area Connect ivity

General Requirements

Wide Area Connect ivity

UMTS

2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) Intersyste m Hando ver and Cell Resele ction Idle Mode Mobilit y

CA_3A-5A DL
CA_3C DL
Fast return from 2G to 3G
IRAT NACC to 2G

Gener TM1-TM4 al

Home Home NodeB NodeB icon

Home Closed NodeB Subscriber
Group

Gener al

Handling of incoming calls for data products

Compl iance with 3GPP specifi cation s Radio

Compliance with 3GPP Radio Access specifications
Data Roaming

All UEs of Cat 6 or higher have to support downlink CA band 3 (1800 + band 5 (850) combination: (min bandwidth 5 MHz + 5 MHz; max bandwidth 20 MHz + 10 MHz)

Important to support higher data rates in the Downlink in Australian OpCo.

3GPP TS 36.101

All UE of Cat 6 or higher have to support downlink CA band 3 (1800) + band 3 (1800) combination, using continuous bands: (min bandwidth 5 MHz + 20 MHz; max bandwidth 15+ 20 MHz) The UE shall respond as appropriate to the "Cell selection indicator after release of all TCH and SDCCH" Information Element in Channel Release message as specified in 3GPP TS 44.018 section 3.4.13.

Important to support higher data rates in the Downlink.

3GPP TS 36.101

This will significantly reduce the time taken by a terminal reselecting 3G after using 2G.

3GPP TS 44.018 section 3.4.13

The LTE UE shall support Inter-RAT NW assisted Cell Change (NACC) to GSM
This requirement will apply to both MIMO and MaMIMO: The UE shall support Transmission Modes: TM1, TM2, TM3 and TM4 according to 3GPP Rel-8. Support for up to 4 layers per UE in DL for TM3/TM4. The UE shall provide an icon indicating that the UE is using a Vodafone femtocell rather than the macro network. The icon appearance an placement will be as agreed on a product by product basis. The UE shall support the Closed Subscriber Group (CSG) feature according to 3GPP TS 25.304 and 25.367.
If the UE is a data centric device without speech handling capabilities, it shall neither reject nor accept incoming speech calls, i.e. the UE shall respond to paging, establish the call set up and then remain in State U7 (Call Received) without answering (i.e. through-connecting) the call). The UE shall comply with Rel-13 and later releases of the 3GPP specifications. Any areas of noncompliance should be noted.

Required for all LTE terminals in order to support IRAT mechanism.
TM1 to TM4: needed to support all the MIMO requirements
Will become important if networks start charging differently depending if using femtocell or macro network.
Required for support of Femto deployments. As Femtocells are now extensively deployed in Vodafone OpCos, it is essential that this is supported Essential for data products to ensure correct behaviour for Multi SIM Subscriptions
3GPP Release 10 is the baseline now for Radio Access features support. Many features of later Releases (Release 11, 12, ..) are now required in addition to this baseline functionality

3GPP TS 36.300 and TS 36.331 3GPP TS 36.213
N/A
N/A
N/A
N/A

The device shall have the option for

Essential to prevent potential bill

N/A

user to turn on/off data roaming. Data shock for roamers using data.

roaming shall be turned OFF by default. Default setting can be modified

where appropriate if user has an

appropriate data roaming package

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE LTE GPRS

Wide Area Connect ivity

GPRS

Conne cted Mode Mobilit y
Conne cted Mode Mobilit y
Conne cted Mode Mobilit y
Conne cted Mode Mobilit y Conne cted Mode Mobilit y Conne cted Mode Mobilit y Conne cted Mode Mobilit y Idle Mode Mobilit y

Inter-RAT Mobility from eUTRAN connected mode to GSM/GPRS idle mode by RRC Connection Release with redirect Inter-RAT Mobility from eUTRAN connected mode to UTRAN Idle mode by RRC Connection Release with redirect RRC connection release / redirection from UTRAN to e-UTRAN Redirection to eUTRAN upon the release of the CS connection Inter-RAT PS HO UTRA HSPA to eUTRA
Inter-RAT PS HO from UTRA to eUTRA
Inter-RAT PS HO to UTRA PS/HSPA with forwarding
BPLMN scan

The UE shall support Inter-RAT Mobility from eUTRAN connected mode to GSM/GPRS idle mode by RRC Connection Release with redirect in case PS HO is not implemented
The UE shall support Inter-RAT Mobility from eUTRAN connected mode to UTRAN Idle mode by RRC Connection Release with redirect (in case PS HO is not implemented)
The UE shall support RRC connection release / redirection from UTRAN to eUTRAN
The UE shall support Redirection to eUTRAN upon the release of the CS connection.
The UE shall support Inter-RAT Packet Switched handover from UTRA HSPA to eUTRA
The UE shall support Inter-RAT Packet Switched handover from UTRA to eUTRA
The UE shall support Inter-RAT Packet Switched handover from eUTRA to UTRA PS/HSPA with forwarding
The multi-RAT UE shall support background PLMN scan when camping on GSM or UMTS cell in order to reselect LTE cell when available.

Essential for all LTE terminals in order to allow inter-RAT redirection.
Essential for all LTE terminals in order to allow inter-RAT redirection.
Essential for all LTE terminals in order to allow inter-RAT redirection.
Essential for all LTE terminals in order to allow inter-RAT redirection.
Essential for all LTE terminals in order to allow inter-RAT PS handover. Essential for all LTE terminals in order to allow inter-RAT PS handover. Essential for all LTE terminals in order to allow inter-RAT PS handover. Ensures that LTE network is used wherever possible

Gener Combined

al

Attach

The UE shall support Combined Attach Essential to ensure good coverage in

to LTE and 2G/3G network

mixed radio environments

N/A
N/A
N/A N/A N/A N/A N/A N/A 3GPP TS 24.301

PDP PDP Type Rel- If the network has returned a PDP IPv4 Essential for support of IPv6

N/A

9 Fallback

assignment to a IPv4v6 request, the

deployment

device shall immediately request a

second primary PDP Context with IPv6

assignment.

PDP PDP Type Rel- The device shall always request a Dual Essential for support of IPv6

N/A

9 Handling

PDP type according to 3GPP Rel-9.

deployment

('8Dh'). If the network does not

understand this (i.e. only pre-Rel-8

compliant) then it is expected that the

network returns PDP IPv4 assignment.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

GSM

Area

Connect

ivity

VAMO VAMOS I S

Wide

General

UI

Area

Requirements

Connect

ivity

Wide

General

UI

Area

Requirements

Connect

ivity

Emergency state indication on display
Radio Access Technology Indicator

Wide

LTE

Area

Connect

ivity

Power DRX Manag ement

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Power DL reference Manag signal ement
Gener LTE Bands al

The device shall support VAMOS 1 as specified in 3GPP TS 45.005.
The UE shall have an indication on display that informs the user about Limited Service state (only Emergency calls allowed)
The UE shall display an indicator to the user, identifying the best radio access technology available from the following list. This shall apply whenever there is an indication of radio access technology to the user: "G" = GPRS "E" = EDGE "3G" = 3G data "H" = HSPA "H+" = HSPA+ (Downlink speed in excess of 14Mbps) "4G" = LTE "4G+" = LTE Carrier Aggregation (Downlink Speed in excess of 150Mbps) ""5G"" = See note below Menu strings for the Network band selection or any other reference to radio interface technologies across the whole device's UI, should use the terms "2G, 3G, 4G" and not "GSM, WCDMA/UMTS, LTE" or similar. Note that the use of "5G" is only permitted for devices connected to a high data rate bearer with capabilities that meet specific criteria (TBD) DRX is a technology in which the user equipment (UE) can switch between active and sleep states. In DRX mode, a DRX cycle consists of active time and sleep time, corresponding to active state and sleep state, respectively. In non-DRX mode, the UE always turns on its receiver and stays in the active state. The UE shall support the Long Cycle, Short Cycle and different DRX per QCI. The UE shall support UE-specific Downlink reference signal.

Lack of support will reduce ability of Vodafone operating companies to make efficient use of available network bandwidth for 2G voice. This is particularly important for 2G devices in emerging markets where there is massive growth in voice traffic with limited network resource Allows user to understand when they are outside of regular coverage Gives clear indication to the user what to expect in terms of data connectivity
Essential for all LTE terminals in order to allow power saving.
Essential for all LTE terminals in order to allow measurements, cell search, etc.

N/A N/A N/A
3GPP TS 36.321 3GPP TS 36.211

For European device variants the UE shall support the following Frequency Bands: * Band 3 (UL: 1710 ­ 1785 MHz, DL: 1805 ­ 1880 MHz) * Band 7 (UL: 2500 ­ 2570 MHz, DL: 2620 ­ 2690 MHz) * Band 20 (UL: 832 ­ 862 MHz, DL: 791 MHz ­ 821 MHz) * Band 1 (UL: 1920 ­ 1980 MHz, DL: 2110 MHz ­ 2170 MHz) * Band 38 (TDD, UL/DL 2570 ­ 2620 MHz) * Band 8 (UL: 880 ­ 915 MHz, DL: 925 ­

Essential for LTE devices as these bands are in use in Vodafone Operating Companies. Band 38 is already available in PT,ES,UK,DE, RO,GR and NZ. Band 38 is mainly thought right now for Small cells, then targeting to have first scenarios end next year end 2016 or later. B42 /B43 is starting to be auctioned in Europe, in VF Radar as key band for 5G evolution. already assigned in RO, MT and NZ, and some OpCos from Vodacom group

3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity
Wide Area Connect ivity

General Requirements
General Requirements

Wide Area Connect ivity

GPRS

Wide Area Connect ivity

UMTS

Wide Area Connect ivity

UMTS

Wide Area Connect ivity

General Requirements

960 MHz)

Band 41 essential for Vodafone India,

* Band 32 (DL: 1452-1496)

which also seeks Band 40 support for

already assigned in DE, IT, and UK.

open market products

* Band 28 (UL: 703 ­ 748MHz, DL: 758

­ 803MHz)

already available in NZ, acquired in DE

and IT, in plan for auction in other EU

markets..

* B42

assigned in RO an in plan in other

markets. B42/B43 are key bands in the

evolution to 5G. No current plans to

use it in 4G

And, on top of Europe:

* Band 41 (TDD, UL/DL 2496 ­ 2690

MHz)

acquired in India, with a variety of

frequencies in the allocated on a per

circle basis.

* Band 5 (UL: 824 ­ 849 MHz, DL: 869 ­

894 MHz)

already available for Vodafone Australia

and in plan in other AMAP markets.

UI

NITZ - Network The device shall select and obtain the Particularly relevant for

3GPP TS

Identity

PLMN ID and display the correct

CPE/femtocell units to identify

22.042

Network Identity information as

location

specified in 3GPP

Autom Network based For device that do not support the use Allows the user to set the time on the N/A

ated Time update of time management through

phone based on the n/w.

Time

connection to a Network Time Protocol Not universally used in Vodafone

Synchr

server on the internet (e.g.

OpCos but required for some

onisati

apple.time.com) the UE shall support a

on

mechanism to update time and date

using network supplied information

such as NITZ or NTP

Gener EDGE Coding The UE shall support Coding schemes Network uses these codecs (MCS 4 N/A

al

scheme

MCS1, MCS2, MCS3, MCS4, MCS5,

not very common). IF not supported,

Requir

MCS6, MCS7, MCS8 & MCS9 as

UE will not be able to inter-operate

ement

specified in 3GPP TS 45.003 Section 5

s

Gener Device Type The UE shall support the "Device Type" Mandatory for data devices only - to N/A

al

Setting

in the UE Capability Parameter as

do with battery management

defined in 3GPP TS25.331.

Gener UMTS Bands I

al

& VIII (FDD)

Roami ng

Steering of Roaming (Managed Roaming)

If the "Device Type" is a mains-powered

Data device, the field shall be set to

<DoesNotBenefitFromBatteryConsump

tionOptimisation> (the UE does not

benefit from battery consumption

optimisations). If the "Device Type" is a

battery-powered data device or a

handset this parameter shall NOT be

set to this value.

A UMTS UE shall support both UMTS Dependant on the support of UMTS N/A

Operating Band I (2100MHz) and UMTS 900 - as specified in the RFP. UMTS

Operating Band VIII (900MHz).

2100 is mandatory for all OpCos and

UMTS900 is now widely used in many

OpCos too

In Automatic Network Selection, after Mandatory for roaming - allows the N/A

the UE has received the fourth location network to steer users to preferred

update reject with Reject Cause #17 networks to reduce the risk of bill

`Network Failure (i.e. attempt counter shock.

>=4), it shall start a new PLMN search

according to 3GPP TS 24.008 section

4.2.1.2, last bullet point. It shall not

wait for the T3212 timer to expire.

The new PLMN search shall happen

according to the following procedure:

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

GSM

Area

Connect

ivity

Wide Area Connect ivity

UMTS

Wide

GSM

Area

Connect

ivity

Radio SAIC

HSDP UE Downlink

A

Category

Radio GSM Bands

- The PLMN search shall be started in any case, independently from the result of the GPRS Attach / Routing Area Update procedure, independently from the Network Mode of Operation (NMO, i.e. Combined or Separate Routing Area Update) and independently of the content of the Preferred PLMN list on the SIM card. - If other PLMNs can be found, the UE shall attempt to perform an IMSI Attach or a Location Update procedure at each of them taking into account the Attempt Counter, according to 3GPP TS 24.008 sections 4.4.4.5, 4.4.4.6 and 4.4.4.9. - If no different PLMN apart from the rejected can be found, the UE shall attempt to select one of the already rejected networks once more (only one additional Location Update cycle, i.e. 4 LU attempts).

Note1: These requirements apply to

both, national and international

roaming

Note2: As per requirements above, if

only one PLMN is available and this

PLMN was already rejected 4 times

with reject cause 17 "network failure"

(i.e. attempt counter >=4) the terminal

device shall perform a new network

scan followed by a new registration

process, which may exist of 4 LU

Requests attempts to the already

rejected network again for one more

time (i.e. max. 2 location update cycles

on the same network).

The UE should support techniques to Radio quality conditions across

N/A

improve downlink performance such as networks are already tight (e.g.

the DARP (Downlink Advance Receiver emerging markets) and is becoming

Performance) Phase I and DARP Phase tighter (particularly in mature

II feature, whereby the UEs must

markets were 900MHz band

comply with the DARP radio

refarming has taken place). DARP

performance specification given in TS capable terminals are more robust

45.005 and must support DARP

against bad radio conditions what

signalling as specified in TS 24.008, i.e., enables the use of other features

the DARP feature must be indicated by that provides capacity efficiency

the UE in the Classmark 3 IE, and where gains (e.g. AMR, VAMOS etc.). The

GPRS is supported in the UE RAC IE.

use of SAIC terminals incorporating

DARP is therefore a key priority.

The UE capability supported for HSDPA This should be as specified and

N/A

shall be as follows:

agreed in RFI.

For data devices the capability

supported for HSDPA shall be Category

10 minimum, with Category 24 being

preferred

For smartphones the capability

supported for HSDPA shall be Category

10 minimum, with Category 24 being

preferred

Please specify Category supported in

Vendor Comments field

The device shall support the following 1900MHz can be compromised if

N/A

GSM Bands:

absolutely necessary, though will

* 850 MHz

have impact on device roaming

* 900 MHz (E-GSM-900)

capability. All other bands are non-

* 1800 MHz

compromisable

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

* 1900 MHz as specified in 3GPP TS 45.005

Wide Area Connect ivity

GPRS

Radio

GPRS Multislot Class

The UE shall support the GPRS Multislot Class greater than Class 8 as specified in 3GPP TS 45.002 Annex B (normative): Multislot capability B.1 MS classes for multislot capability

This is agreed in the RFP.

3GPP TS 44.018

Wide Area Connect ivity
Wide Area Connect ivity

GPRS
General Requirements

APN APN support
Regula IMEI SV tions Support

Wide Area Connect ivity

General Requirements

Regula Unique TAC tions

Wide

GSM

Area

Connect

ivity

Wide

GSM

Area

Connect

ivity

PLMN

Preferred PLMN list (PLMNSel or PLMNwAcT)

Radio Quadruple Rate Codec

Please state Multi-Slot Class in Vendor

Comment section.

UE shall support a total APN length

This is to do with the ability to

N/A

(Network Identifier+Operator Identifier) distinguish the APN on a per operator

of 100 octets.

basis.

The UE shall support the IMEI Software Version (IMEISV) and it shall be properly managed by the Manufacturer so that:
- The SV shall be incremented for each new software release and maintenance release - The SV number for each Vodafone variant SW must not be the same as the open market variant - In case multiple OpCos share the same ROM the SV number may be the same for those OpCos - SV number shall be independent across different terminals and the vendor can choose the increment pattern for the SV number - All software release notes shall contain a mapping table that specifies the mapping between IMEISV and the device software version The UE shall have a TAC allocated by a GSMA or its associated reporting bodies according to the current IMEI allocation rules (GSMA PRD TS.06 & TS.16) allowing the UE type to be identified; in case of large volume of production several TAC codes can be used . The unique TAC (First 8 digits of the IMEI) or the multiple TAC granted to a type of terminal must identify this terminal type without ambiguity. The use of the 9th digit of the IMEI to identify a terminal type or variant is not permitted. The preferred PLMN list (PLMNSel or PLMNwAcT) shall only be overwritten by the UE if expressly required by the user, not as a `by product' of any other action such as a manual network selection. This requirement should not exclude the Operator updating the PLMN list. All devices shall have a HR + EFR + FR + AMR/H + AMR/F codec.

Device will NOT be able to offer IMEI SV (software version) tracking capabilities. Where SV will allow us to track field issues relating to a particular IMEI. Particularly important with devices that can have firmware updated OTA or by user
Essential to identify individual devices on the network
Only the user or the operator can be allowed to update the preferred PLMN list. If not supported the network search algorithm would not work correctly.
Various codecs used. All are important - HR still used

N/A
GSMA PRD TS.06 & TS.16
N/A N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

GSM

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

USSD USSD Message Up to 160 digit/character USSD

Essential for support of PAYG credit N/A

length

messages shall be passed on the uplink management and other services

as defined in 3GPP TS 29.002. USSD

shall be supported in dedicated mode

2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band)

CA_1A-28A DL
CA_7A-8A DL
CA_8A-28A DL
CA_7A-32A DL
CA_1A-32A DL
CA_20A-28A DL
CA_3A-8A-28A DL
CA_1A-8A-28A DL
CA_7A-8A-28A DL CA_3C-28A DL

All UE of Cat 6 or higher have to support downlink CA band 1 (2100) + band 28 (700) combination
All UE of Cat 6 or higher have to support downlink CA band 7 (2600) + band 8 (900) combination
All UE of Cat 6 or higher have to support downlink CA band 8 (900) + band 28 (700) combination
All UE of Cat 6 or higher have to support downlink CA band 7 (2600) + band 32 (1400) combination
All UE of Cat 6 or higher have to support downlink CA band 1 (2100) + band 32 (1400) combination
All UE of Cat 6 or higher have to support downlink CA band 20 (800) + band 28 (700) combination
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 8 (900) + band 28 (700 APAC) combination.
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 8 (900) + band 28 (700 APAC) combination.
All UEs of Cat 9 or higher have to support downlink CA band 7 (2600) + band 8 (900) + band 28 (700 APAC) combination.
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 28 (700 APAC) combination.

Essential to ensure sufficient

N/A

bandwidth for acceptable data rates:

In New Zealand available now. In

Germany by 2H19

Important to support higher data

N/A

rates in the Downlink in Europe.

Support requested by Q4-2015.

Important to support higher data

N/A

rates in the Downlink in Europe.

Support requested by Q4-2015.

Important to support higher data

N/A

rates in the Downlink. In UK by 2H19.

Important to support higher data

N/A

rates in the Downlink. In UK by 2H19.

Important to support higher data

N/A

rates in the Downlink. In Netherlands

by 2H20.

Important to support higher data

N/A

rates in the Downlink.

Important to support higher data

N/A

rates in the Downlink.

Important to support higher data

N/A

rates in the Downlink. In Germany by

2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in New Zeland and in Germany by

2H19.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band)

CA_1A-3C DL
CA_3C-8A DL
CA_1A-8A-38A DL
CA_3A-8A-38A DL
CA_7A-20A32A DL
CA_1A-7A-32A DL
CA_8A-20A28A DL
CA_3A-20A28A DL
CA_1A-20A28A DL
CA_7A-20A28A DL
CA_3A-8A-41A DL

All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) combination.
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 8 (900) combination.
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 8 (900) + band 38 (2600 TDD) combination.
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 8 (900) + band 38 (2600 TDD) combination.
All UEs of Cat 9 or higher have to support downlink CA band 7 (2600) + band 20 (800) + band 32 (1400) combination
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 32 (1400) combination
All UEs of Cat 9 or higher have to support downlink CA band 8 (900) + band 20 (800) + band 28 (700 APAC) combination
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 20 (800) + band 28 (700 APAC) combination
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 20 (800) + band 28 (700 APAC) combination
All UEs of Cat 9 or higher have to support downlink CA band 7 (2600) + band 20 (800) + band 28 (700 APAC) combination
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 8 (900) + band 41 (2500 TDD) combination

Important to support higher data

N/A

rates in the Downlink. Available now

in New Zeland and Romania.

Important to support higher data

N/A

rates in the Downlink. Available in

Romania and Germany by 2H19.

Important to support higher data

N/A

rates in the Downlink in Europe.

Important to support higher data

N/A

rates in the Downlink in Europe.

Important to support higher data

N/A

rates in the Downlink. Available In UK

by 2H19.

Important to support higher data

N/A

rates in the Downlink. Available In UK

by 2H19.

Important to support higher data

N/A

rates in the Downlink. Available In

Netherlands by 2H20.

Important to support higher data

N/A

rates in the Downlink. Available In

Netherlands by 2H20.

Important to support higher data

N/A

rates in the Downlink. Available In

Netherlands by 2H20.

Important to support higher data

N/A

rates in the Downlink. Available In

Netherlands by 2H20.

Important to support higher data

N/A

rates in the Downlink. Available in

India by 2H19.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

3 Carrier Aggre gation (Multi Band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band) 4 Carrier Aggre gation (Multi band)

CA_3A-40A41A DL
CA_1A-3C-28A DL
CA_3C-7A-28A DL
CA_1A-3C-7A DL
CA_1A-3A-8A38A DL
CA_1A-3C-8A DL
CA_3C-8A-38A DL
CA_1A-3C-20A DL
CA_1A-7A20A-38A DL
CA_1A-7A-8A20A DL
CA_1A-3A20A-28A DL

All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 40 (2300 TDD) + band 41 (2500 TDD) combination
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 28 (700) combination.
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 28 (700) combination.
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) combination.
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 8 (900) + band 38 (2600 TDD) combination:
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 8 (900) combination.
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 8 (900) + band 38 (2600 TDD) combination.
All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 20 (800) combination.
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 20 (800) + band 38 (2600 TDD) combination.
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 8 (900) + band 20 (800) combination.
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 20 (800) + band 28 (700) combination.

Important to support higher data

N/A

rates in the Downlink. Available in

India by 2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in New Zeland and in Germany by

2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in New Zeland and in Germany by

2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in New Zeland and in Germany by

2H19.

Important to support higher data

N/A

rates in the Downlink. In Spain and

Greece by 2H20.

Important to support higher data

N/A

rates in the Downlink. In Germany by

2H19.

Important to support higher data

N/A

rates in the Downlink. In Germany by

2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in Romania and in Germany by 2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in UK.

Important to support higher data

N/A

rates in the Downlink. In UK by 2H19.

Important to support higher data

N/A

rates in the Downlink. In Netherlands

by 2H20.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

4

CA_3A-8A-

All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-28A DL support downlink CA band 3 (1800) + rates in the Downlink. In Netherlands

Aggre

band 8 (900) + band 20 (800) + band by 2H20.

gation

28 (700) combination.

(Multi

band)

4

CA_1A-8A-

All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-28A DL support downlink CA band 1 (2100) + rates in the Downlink. In Netherlands

Aggre

band 8 (900) + band 20 (800) + band by 2H20.

gation

28 (700) combination.

(Multi

band)

4

CA_7A-8A-

All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-28A DL support downlink CA band 7 (2600) + rates in the Downlink. In Netherlands

Aggre

band 8 (900) + band 20 (800) + band by 2H20.

gation

28 (700) combination.

(Multi

band)

4

CA_3A-7A-

All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-28A DL support downlink CA band 3 (1800) + rates in the Downlink. In Netherlands

Aggre

band 7 (2600) + band 20 (800) + band by 2H20.

gation

28 (700) combination.

(Multi

band)

4

CA_1A-3A-8A- All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 41A DL

support downlink CA band 1 (2100) + rates in the Downlink. In India by

Aggre

band 3 (1800) + band 8 (900) + band 2H19.

gation

41 (2500 TDD) combination.

(Multi

band)

4

CA_3A-8A-

All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 40A-41A DL support downlink CA band 3 (1800) + rates in the Downlink. In India by

Aggre

band 8 (900) + band 40 (2300 TDD) + 2H19.

gation

band 41 (2500 TDD) combination.

(Multi

band)

4

CA_1A-3A-

All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 40A-41A DL support downlink CA band 1 (2100) + rates in the Downlink. In India by

Aggre

band 3 (1800) + band 40 (2300 TDD) + 2H19.

gation

band 41 (2500 TDD) combination.

(Multi

band)

5

CA_1A-3A-3A- All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 8A-38A DL

support downlink CA band 1 (2100) + rates in the Downlink. In Romania by

Aggre

band 3 (1800) + band 3 (1800) + band 1H19.

gation

8 (900) + band 38 (2600 TDD)

(Multi

combination

Band)

5

CA_1A-7A-8A- All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-38A DL support downlink CA band 1 (2100) + rates in the Downlink. In UK by 2H19.

Aggre

band 7 (2600) + band 8 (900) + band

gation

20 (800) + band 38 (2600 TDD)

(Multi

combination

Band)

5

CA_1A-7A-8A- All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-32A DL support downlink CA band 1 (2100) + rates in the Downlink. In UK by 2H19.

Aggre

band 7 (2600) + band 8 (900) + band

gation

20 (800) + band 32 (1400 SDL)

(Multi

combination

Band)

5

CA_3A-7A-8A- All UEs of Cat 11 or higher have to

Important to support higher data

N/A

Carrier 20A-28A DL support downlink CA band 3 (1800) + rates in the Downlink. In Netherlands

Aggre

band 7 (2600) + band 8 (900) + band by 2H20.

gation

20 (800) + band 28 (700) combination

(Multi

Band)

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

5 Carrier Aggre gation (Multi Band) 5 Carrier Aggre gation (Multi Band) 5 Carrier Aggre gation (Multi Band) 5 Carrier Aggre gation (Multi Band) 6 Carrier Aggre gation (Multi Band) 6 Carrier Aggre gation (Multi Band) UL Carrier Aggre gation

CA_1A-3A-7A20A-28A DL
CA_1A-3A-8A20A-28A DL
CA_1A-3A-8A40A-41A DL
CA_1A-3A-7A20A-32A DL
CA_1A-7A-8A20A-32A-38A DL
CA_1A-3A-7A8A-20A-28A DL
CA_3A-8A UL

UL Carrier Aggre gation

CA_1A-7A UL

UL Carrier Aggre gation

CA_8A-20A UL

UL Carrier Aggre gation

CA_1A-8A UL

UL Carrier Aggre gation

CA_7A-8A UL

UL Carrier Aggre gation

CA_8A-28A UL

Licens e Assiste d Access

CA_41A-46A

All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 20 (800) + band 28 (700) combination
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 8 (900) + band 20 (800) + band 28 (700) combination
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 8 (900) + band 40 (2300 TDD) + band 41 (2500 TDD) combination
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 20 (800) + band 32 (1400 SDL) combination
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 8 (900) + band 20 (800) + band 32 (1400 SDL) + band 38 (2600 TDD) combination.
All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 8 (900) + band 20 (800) + band 28 (700) combination.
All UEs of Cat 6 or higher have to support CA in UL band 3 (1800) + band 8 (900)
All UEs of Cat 6 or higher have to support CA in UL band 1 (2100) + band 7 (2600)
All UEs of Cat 6 or higher have to support CA in UL band 8 (900) + band 20 (800)
All UEs of Cat 6 or higher have to support CA in UL band 1 (2100) + band 8 (900)
All UEs of Cat 6 or higher have to support CA in UL band 7 (2600) + band 8 (900)
All UEs of Cat 6 or higher have to support CA in UL band 8 (900) + band 28 (700)
The UE shall support License Assisted Access utilising DL carrier aggregation of band 41 (2500 TDD) + band 46 (5GHz Unlicenced)

Important to support higher data

N/A

rates in the Downlink. In Netherlands

by 2H20.

Important to support higher data

N/A

rates in the Downlink. In Netherlands

by 2H20.

Important to support higher data

N/A

rates in the Downlink. In India by

2H19.

Important to support higher data

N/A

rates in the Downlink. Available now

in Germany.

Important to support higher data

N/A

rates in the Downlink. In UK by 2H20.

Important to support higher data

N/A

rates in the Downlink. In Netherlands

by 2H20.

Important to support higher data

N/A

rates in the Uplink.

Important to support higher data

N/A

rates in the Uplink.

Important to support higher data

N/A

rates in the Uplink. In UK by 2H19.

Important to support higher data

N/A

rates in the Uplink. In New Zeland by

2H19.

Important to support higher data

N/A

rates in the Uplink. In New Zeland by

2H19.

Important to support higher data

N/A

rates in the Uplink. In New Zeland by

2H19.

Important to support higher data

N/A

rates in DL including the unlicence

spectrum. Support requested in India

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE GSM 5G 5G 5G 5G 5G General Requirements

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT LTE-IoT

Licens e Assiste d Access Licens e Assiste d Access MIMO

CA_41A-46C
CA_1A-46A
SRS antenna switching

Cipher A5/4

ing

Ciphering

Algorithm

RRC Idle state States

VoLTE VoLTE Service RRC

VoLTE VoLTE Service PS HO

Latenc UE processing

y

time cap#1

Latenc UE processing

y

time cap#2

Locati on

Cellular assisted Real Time Kinematic (RTK) positioning as defined in Rel15

Batter y Life Extens ion
Batter y Life Extens ion
Batter y Life Extens ion

Connected DRX - LTE-IoT Mode A
Connected DRX - LTE-IoT Mode B
Wake-up signalling for IDLE mode (Rel-15)

The UE shall support License Assisted Access utilising DL carrier aggregation of band 41 (2500 TDD) + band 46 x2 (5GHz Unlicenced)
The UE shall support License Assisted Access utilising DL carrier aggregation of band 1 (2100) + band 46 (5GHz Unlicenced)
Support for SRS antenna switching for 1T2R
KASUMI 128-bit ciphering key encryption for control channels, circuit switched voice traffic channels.
Support for prioritisation of 5GC as preferred CN type in RRC_IDLE state when sleecting a cell supporting both CN types The device will support RRC release with redirection mechanism to steer the user from option 2 to option 1 for VoLTE service. The device will support PS HO mechanism to steer the user from option 2 to option 1 for VoLTE service.
UE processing time as defined per 3GPP capability # 1
UE processing time as defined per 3GPP capability # 2
The device shall support new high accuracy GNSS positioning method
Support DRX in connected mode for deployment mode A
Support DRX in connected mode for deployment mode B
When a UE is in DRX or eDRX, it must regularly check if a paging message is arriving from the core network.

Important to support higher data

N/A

rates in DL including the unlicence

spectrum. Support requested in India

Important to support higher data

N/A

rates in DL including the unlicence

spectrum. Available in Turkey. In

Ireland and Romania by 2H20.

Now

N/A

Essential for any GSM device

N/A

By 2H20

N/A

By Q419

N/A

By Q419

N/A

By Q219

N/A

By 2H20

N/A

GPS info is today available to the end N/A

user in most smartphones (provided

the UE position allows to receive the

GPS signal), but it's not available to

the Radio Access Layer for any NW

optimization based on UE location.

GPS accuracy is much better than the

one obtained using other methods

like OTDOA and its evolutions

Now

N/A

Now

N/A

By Q219

N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE-IoT

Batter Early data

An idle mode UE is able to transmit

By Q219

N/A

Area

y Life transmission data in Msg3 of the random access

Connect

Extens (Rel-15)

procedure, carrying between 328 and

ivity

ion

1000 bits.

Wide

LTE-IoT

Batter RLC UM (Rel- Support for RLC unacknowledged

By Q219

N/A

Area

y Life 15)

mode (UM) to complement the

Connect

Extens

acknowledged mode (AM) and

ivity

ion

transparent mode (TM) introduced in

Rel-13

Wide

NB-IoT

Batter Scheduling

In Rel-13/14 NB-IoT, scheduling

By Q219

N/A

Area

y Life request (Rel- request (SR) exists only as a higher-

Connect

Extens 15)

layer procedure, which triggers a

ivity

ion

random access procedure to request

sufficient UL resource to send a buffer

status report (BSR). For Rel-15 For a

connected mode UE, eNB is able to

configure by RRC periodic NPUSCH

resources for the UE to send BSR, so

the eNB is informed when pending

traffic has arrived in the UE's buffer

Wide

NB-IoT

Batter RLC UM (Rel- Support for RLC unacknowledged

By Q219

N/A

Area

y Life 15)

mode (UM) to complement the

Connect

Extens

acknowledged mode (AM) and

ivity

ion

transparent mode (TM) introduced in

Rel-13

Wide

NB-IoT

Batter Reduced

When SIB1-NB is being transmitted

By Q219

N/A

Area

y Life system

with 16 repetitions (the maximum

Connect

Extens acquisition

supported), eNB can transmit

ivity

ion

time (Rel-15) additional subframes containing SIB1-

NB repetitions on anchor carriers and

non-anchor carriers to allow faster

decoding of SIB1-NB and reduce the

UE's power consumption during cell

access

Wide

LTE-IoT

Locati e-CID

Support E-CID based positioning (Rel- By Q219

N/A

Area

on

13)

Connect

ivity

Wide

NB-IoT

Locati e-CID (Rel-14) The device shall support enhanced Rel- Now

N/A

Area

on

14 positioning protocols: e-CID

Connect

ivity

Wide

NB-IoT

Servic Higher density Improved load control with level-based By Q219

N/A

Area

es

support (Rel- access class barring (Rel-15). The ACB

Connect

15)

mechanism shall work in dynamic

ivity

mode with dynamic Access Class

barred per barring period. The barring

intensity will be dependent on the

status of congestion

Wide

NB-IoT

Cell Cell size

NPRACH range enhancement. A new By Q419

N/A

Area

Size extension

NPRACH format is introduced with a

Connect

120Km (Rel- subcarrier spacing of 1.25 kHz and a

ivity

15)

cyclic prefix of 800 s, together with

frequency hopping, which is sufficient

to allow unambiguous range

determination up to 120 km.

Wide

LTE-IoT

Deplo VoLTE for

VoLTE service can be supported up to Now

N/A

Area

yment deployment Deployment mode A

Connect

Option Mode A

ivity

Wide

LTE-IoT

Deplo VoLTE for

VoLTE service can be supported up to Now

N/A

Area

yment deployment Deployment mode B

Connect

Option Mode B

ivity

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT LTE-IoT LTE-IoT LTE-IoT LTE-IoT

Wide Area Connect ivity

NB-IoT

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Deplo Higher UE

Enhanced performance requirements By Q220

N/A

yment velocity (Rel- are introduced for CE mode A. These

Option 15)

requirements are defined for 200 Hz

Doppler spread, corresponding to

around 240 km/h at 1 GHz and 120

km/h at 2 GHz.

Deplo UL max Tx

eNb can manage devices supporting up By Q220

N/A

yment power 14

to 14 dBms tx power

Option dBms (Rel-15)

Deplo Deployment Support of repetitions with

By Q219

N/A

yment mode A for any Deployment mode A for all LTE from

Option LTE Cat

Cat 1 (included) in LTE eNB in co-

existence with all LTE UE categories.

Deplo Deployment Support of repetitions with

By Q219

N/A

yment mode B for any Deployment mode B for all LTE from

Option LTE Cat

Cat 1 (included) in LTE eNB in co-

existence with all LTE UE categories.

Efficie Downlink

Support for 64QAM modulation for

By Q419

N/A

ncy 64QAM - LTE- PDSCH unicast transmission without

IoT

repetition in CE mode A to increase the

downlink spectral efficiency

Efficie Uplink sub-

Introduction of PUSCH sub-PRB

By Q419

N/A

ncy PRB allocation resource allocation in connected

mode. New allocation sizes are ½ PRB

(6 subcarriers) or ¼ PRB (3 subcarriers).

In the latter case, a new /2-BPSK

modulation can be used

TDD TDD support UE category NB2, 2 UL/DL HARQ

By Q220

N/A

(Rel-15)

processes, multi-carrier RACH and

paging, and OTDOA. All LTE UL/DL

subframe configurations are supported,

except for configurations 0 and 6, and

all LTE special subframe configurations

are supported

Dual DC_1A-3C-7A- Support of Dual connectivity between By 2H19 for NZ

N/A

Conne 28A_n78A

the specified 5 LTE carriers + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 5

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_1A-3A-7A- Support of Dual connectivity between By 2H19 for DE. By 2H20 for ES and N/A

Conne 8A_n78A

the specified 4 LTE carriers + 1 5G NR NZ.

ctivity

carrier up to 135 MHz, with detailed

- 5

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_1A-3C-

Support of Dual connectivity between By 2H19 for NZ and DE.

N/A

Conne 7A_n78A

the specified 4 LTE carriers + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 4

bandwidth granularity.

Bands

-

InterB

and

EN-DC

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
within FR1

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual DC_1A-3A-

Support of Dual connectivity between By 2H19 for DE. By 2H20 for ES and N/A

Conne 8A_n78A

the specified 3 LTE carriers + 1 5G NR NZ.

ctivity

carrier up to 135 MHz, with detailed

- 4

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_3A-8A-

Support of Dual connectivity between By 2H19 for DE and ES.

N/A

Conne 20A_n78A

the specified 3 LTE carriers + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 4

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_3A-

Support of Dual connectivity between By 2H19 for DE and ES. By 2H20 for N/A

Conne 8A_n78A

the specified 2 LTE carriers + 1 5G NR NZ.

ctivity

carrier up to 135 MHz, with detailed

- 3

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_8A_n20A Support of Dual connectivity between By 2H20 for TR.

N/A

Conne

the specified 1 LTE carrier + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 2

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_3A_n28A Support of Dual connectivity between By 2H19 for DE. By 2H20 for UK and N/A

Conne

the specified 1 LTE carrier + 1 5G NR NL.

ctivity

carrier up to 135 MHz, with detailed

- 2

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_20A_n3A Support of Dual connectivity between By 2H20 for NL.

N/A

Conne

the specified 1 LTE carrier + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 2

bandwidth granularity.

Bands

-

InterB

and

EN-DC

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
within FR1

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Dual DC_8A_SUL_n Support of Dual connectivity with

By 2H19 for UK and by 2H20 for DE. N/A

Conne 78A-n81A

Supplementary Uplink (SUL) between

ctivity

the specified 1 LTE carriers + 1 5G NR

- 2

carrier up to 30 MHz, with detailed

Bands

bandwidth granularity.

-

InterB

and

EN-DC

within

FR1

Dual DC_20A_n8- Support of Dual connectivity between By 2H19 for UK.

N/A

Conne n75/76

the specified 1 LTE carrier + 2 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 3

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_1A-7A-

Support of Dual connectivity between By 2H20 for UK.

N/A

Conne 20A_n8A

the specified 3 LTE carrier + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 3

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_1A-7A-

Support of Dual connectivity between By 2H20 for UK.

N/A

Conne 20A-32A_n8A the specified 4 LTE carrier + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 5

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_1A-7A-

Support of Dual connectivity between By 2H20 for UK.

N/A

Conne 20A-38A_n8A the specified 4 LTE carrier + 1 5G NR

ctivity

carrier up to 135 MHz, with detailed

- 5

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Dual DC_1A-7A-

Support of Dual connectivity between By 2H20 for UK.

N/A

Conne 20A-32A-

the specified 5 LTE carrier + 1 5G NR

ctivity 38A_n8A

carrier up to 135 MHz, with detailed

- 6

bandwidth granularity.

Bands

-

InterB

and

EN-DC

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
within FR1

Wide

5G

Dual DC_1A-7A-

Support of Dual connectivity between By 2H20 for UK.

N/A

Area

Conne 20A_n28A

the specified 3 LTE carrier + 1 5G NR

Connect

ctivity

carrier up to 135 MHz, with detailed

ivity

- 4

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Wide

5G

Dual DC_1A-7A-8A- Support of Dual connectivity between By 2H20 for UK.

N/A

Area

Conne 20A_n28A

the specified 4 LTE carrier + 1 5G NR

Connect

ctivity

carrier up to 135 MHz, with detailed

ivity

- 5

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Wide

5G

Dual DC_1A-7A-8A- Support of Dual connectivity between By 2H20 for UK.

N/A

Area

Conne 20A_n78A

the specified 4 LTE carrier + 1 5G NR

Connect

ctivity

carrier up to 135 MHz, with detailed

ivity

- 5

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Wide

5G

Dual DC_1A-7A-8A- Support of Dual connectivity between By 2H20 for UK.

N/A

Area

Conne 20A-

the specified 5 LTE carrier + 1 5G NR

Connect

ctivity 32A_n28A

carrier up to 135 MHz, with detailed

ivity

- 6

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Wide

5G

Dual DC_1A-7A-8A- Support of Dual connectivity between By 2H20 for UK.

N/A

Area

Conne 20A-

the specified 5 LTE carrier + 1 5G NR

Connect

ctivity 32A_n78A

carrier up to 135 MHz, with detailed

ivity

- 6

bandwidth granularity.

Bands

-

InterB

and

EN-DC

within

FR1

Wide

5G

Dual DC_1A-7A-8A- Support of Dual connectivity between By 2H20 for UK.

N/A

Area

Conne 20A-

the specified 5 LTE carrier + 1 5G NR

Connect

ctivity 38A_n28A

carrier up to 135 MHz, with detailed

ivity

- 6

bandwidth granularity.

Bands

-

InterB

and

EN-DC

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
within FR1

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

5G 5G 5G 5G LTE - Voice and Messaging

Dual Conne ctivity - 6 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 7 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 7 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 3 Bands InterB and EN-DC within FR1 CSFB

DC_1A-7A-8A20A38A_n78A
DC_1A-7A-8A20A-32A38A_n28A
DC_1A-7A-8A20A-32A38A_n78A
DC_20A7A_n3A
CSFB Support

Support of Dual connectivity between the specified 5 LTE carrier + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity.
Support of Dual connectivity between the specified 6LTE carrier + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity.
Support of Dual connectivity between the specified 6 LTE carrier + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity.
Support of Dual connectivity between the specified 2 LTE carrier + 1 5G NR carrier up to 135 MHz, with detailed bandwidth granularity.
The UE shall support CSFB procedures according to 3GPP TS 23.272 Rel-13 or later. This includes: * Combined Attach to CS and PS services * Combined TAU * CSFB to UTRAN with RRC connection release and redirection with gap measurements (including RIM procedure) * CSFB to UTRAN with PS handover without measurement gaps * CSFB to GPRS/EDGE with RRC connection release and redirect (including RIM procedure) * CSFB to GPRS/EDGE with CCO (with NACC) * CSFB for Supplementary Services and USSD In case of non or partial compliance,

By 2H20 for UK. By 2H20 for UK. By 2H20 for UK. By 2H20 for NL. Essential for LTE UE offering voice and messaging capability

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

N/A N/A N/A N/A 3GPP TS 23.272

Vodafone Group Products & Service

please state the known limitations in the comment sections.

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT NB-IoT LTE-IoT

Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE-IoT NB-IoT LTE-IoT

Wide Area Connect ivity

LTE-IoT

Gener al
Locati on Locati on

FGI bit pattern for Rel-9 onwards, bit 16-32
LPP A-GNSS LTE-IoT LPP A-GNSS NB-IoT

The following bit pattern (TS 36.331, Annex B, Table B.1-1) shall be at least supported by the UE: FGIbit 16: 1 (intra/interfreq & interRAT meas) bit 17: 1 (ANR-intraFreq) bit 18: 1 (ANR-interFreq) bit 19: 1 (ANR-interRAT) bit 20: 1 (DRB combi) bit 21: X bit 22: 1 (UTRAN meas, Event B2) bit 23: 1 (GERAN meas, Event B1) bit 24: X bit 25: 1 (EUTRAN meas, Event B2) bit 26: X bit 27: 1 (VoLTE, SRVCC CS) bit 28: 1 (TTI bundling) bit 29: 1 (SPS) bit 30: 1 (HO FDD<->TDD) bit 31: X bit 32: undefined - The FGI bits marked with "X" are not required to be set. This pattern is valid for all UE from Rel-9 onwards. - In case of non or partial compliance, please state the known limitations in the comment sections. If the device supports GNSS, it should include GNSS measurements in LPP TS 36.355 (A-GNSS). In both CE Mode A and Mode B.
If the device supports GNSS, it should include GNSS measurements in LPP TS36.355 (A-GNSS)

Required for essential NW features, and for NW planning and testing issues in order to select test cases.
Now Now

3GPP TS 36.331, Annex B

Locati on
Locati on

MDT (Minimization of Drive Tests LTE-IoT)
OTDOA - LPP LTE-IoT

The device shall support Minimization of Drive Test feature including GNSS measurements reports (Standalone UE GPS) in idle and connected mode as defined in TS 37.320 Section 5.4.1 UE capabilities. In both Mode-A and Mode-B. The device shall inform if supports OTDOA and is included in LPP

Now For Information

Locati OTDOA - LPP - The device shall inform if supports

on

NB-IoT

OTDOA and is included LPP

For Information

Locati on

LTE Positioning Protocol (LPP) - LTE-IoT

Capaci ty and Scalab ility

Hopping in dedicated channels LTE-IoT

The device shall support LPP protocol including Rel-14 enhancements of 3GPP TS 36.355 section 6.5.3 Enhanced Cell ID Positioning. In both CE Mode A and Mode B. The device shall support frequency hopping on dedicated channels

Now Improves network access

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity

LTE-IoT

Capaci ty and Scalab ility

Hopping in common channels - NBIoT

The device shall support frequency hopping on common channels

Improves network access

Wide Area Connect ivity

NB-IoT

Covera ge Extens ion

UL Coverage class selection

The device shall support 3 coverage class selection for NPRACH based on RSRP and SINR

Improves network access

Wide Area Connect ivity

NB-IoT

Servic Class barring The device shall support access class now

es

barring as specified in the 3GPP

standard

Wide Area Connect ivity

NB-IoT

Wide Area Connect ivity

NB-IoT

Mobilit InterRAT cell

y

reselection

Mobilit y

Intrafrequency cell reselection IoT

The device shall search in an optimum manner for other IoT technologies like CAT-M, LTE or 2G in case of NB-IoT service/coverage loss or for performance improvement (e.g. throughput, battery) if the device supports more than NB-IoT The device shall support intra frequency cell reselection in idle with Rel-14 improvements

Now Improves network access

Wide Area Connect ivity

NB-IoT

Maxim CAT-NB1

The CAT-NB1 device shall be able to Now

um Lower Output reach up to 14 dBm of maximum

output power

transmit power (Rel-14)

Power

Wide Area Connect ivity

NB-IoT

IP

TCP

protoc

ol

The NB-IoT Device shall support TCP.

Wide Area Connect ivity

NB-IoT

CoAP CoAP over NAS The NB-IoT Device shall support CoAP

non-IP

over NAS non-IP mode

Wide Area Connect ivity

NB-IoT

CoAP CoAP over TCP The NB-IoT Device shall support CoAP over TCP

Wide

NB-IoT

DECO Dynamic

The device shall support Rel-13 Décor

N/A

Area

R

management functionality, e.g. the ability to reroute

Connect

suppor of NB-IoT

the UE's connection to the correct

ivity

t for connections MME.

NB-IoT

Wide

NB-IoT

Capaci Anchor PRB - The device shall support 164 dB MCL

N/A

Area

ty

coverage

coverage extension for PUSCH/PDSCH

Connect

extens

in the additional PRB.

ivity

ion

Wide

LTE-IoT

DECO Dynamic

Support Rel-13 Décor functionality, e.g. Medium

N/A

Area

R

management the ability to reroute the UE's

Connect

suppor of Cat-M

connection to the correct MME.

ivity

t for devices

NB-IoT

Wide

LTE-IoT

Radio Enable high The device shall support IoT operation Low

N/A

Area

Robus speed users to at speeds up to 350 km/h. Please

Connect

tness access the

specify the top speed supported.

ivity

and network

Perfor

mance

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide Area Connect ivity

LTE-IoT

Wide

5G

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Radio Robus tness and Perfor mance Capaci ty and Scalab ility

Enhanced UL Power Control, to reduce interference and increase resilience. MTC Transmission: Congestion Control

Capaci ty and Scalab ility

Extended Access Barring (EAB)

VoLTE ViLTE

Support for dynamic adjustment of the uplink PS power control for cat 0, cat 1, and cat M IoT Devices to increase cell edge performance and reduce battery usage.
Support for the extendedWaitTime parameter in the RRC Connection Release and RRC Connection Reject messages in the event of RAN node congestion. Feature for controlling Mobile Originating access attempts from UEs that are configured for EAB, specifically M2M devices, in order to prevent overload of the LTE access network and/or the core network generating by these EAB UE. Compliance to Rel-11 required. The UE shall support of QCI = 2 for Video (ViLTE)* via 4G eNB when there is a 5G NR NSA established

Medium By Q2/19

N/A
3GPP TS 36.331
3GPP TS 36.331, Rel-11

3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 3 Carrier Aggre gation (Multi Band) 5 Carrier Aggre gation (Multi Band)
5 Carrier Aggre gation (Multi Band)
4 Carrier Aggre gation (Multi

CA_1A-7A-8A DL
CA_1A-3A-38A DL
CA_7A-8A-20A DL
CA_3A-7A-8A DL
CA_1A-3C-7A28A DL
CA_1A-3A-7A8A-20A DL
CA_1A_3C_20 A DL

All UE of Cat 9 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 8(900) combination: Bandwidth B1 (5-20 MHz); B7 (15-20 MHz); B8 (5-20 MHz) All UE of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 38 (2600 TDD) combination: bandwidth B1 (5-20 MHz); B3 (10-20 MHz); B38 (15-20 MHz) All UE of Cat 9 or higher have to support downlink CA band 7 (2600) + band 8 (900) + band 20 (700) combination: Bandwidth B7 (15-20 MHz); B8 (5-15 MHz); B20 (10 MHz) All UE of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 8 (900) combination: Bandwidth B3 (10-20 MHz); B7 (15-20 MHz); B8 (5-15 MHz) all UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 3 (1800) contiguous + band 7 (2600) + band 28 (700) combination: Bandwidth: B1 (5-20 MHz) + B3 (10-25 MHz) + B7 (15-20 MHz) + B28 (5-15 MHz) All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 8 (900) + band20 (800) combination: Bandwidth: B1 (5-20 MHz) + B3 (10-20 MHz) + B7 (15-20 MHz) + B8 (5-15 MHz) + B20 (10 MHz) All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 3 (1800) contiguous + band 20 (800) combination:

Essential to ensure sufficient bandwidth for acceptable data rates: TR in 2H 2019
Essential to ensure sufficient bandwidth for acceptable data rates: TR in 2H 2019
Essential to ensure sufficient bandwidth for acceptable data rates: TR in 2H 2018
Essential to ensure sufficient bandwidth for acceptable data rates: TR in 2H 2018
Important to support higher data rates in the Downlink in Europe and AMAP. By 2H19 in New Zeland and Germany.
Important to support higher data rates in the Downlink in Europe and AMAP. By 2H18 in TR
Essential to ensure sufficient bandwidth for higher data rates: Romania by 1H 2019

3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Band)
5G NR TDD configuration 8:2

(min bandwidth 5 MHz + 20 MHz + 5MHz + 10 MHz; max bandwidth 20 MHz + 20MHz + 5MHz + 20MHz)
The UE shall support 5GNR 8:2 DL:UL config to sync with 4G TDD config 2, periodicity 5 ms

by Q219

5G NR TDD configuration 4:1

The UE shall support 5GNR 4:1 DL:UL, periodicity of duty cycle 2.5 ms

by Q219

Latenc y
Latenc y

short PUCCH channel: PUCCH format 2
Short PUCCH channel

Short PUCCH channel: PUCCH format 2 over 1-2 OFDM symbols once per slot with FH
Short PUCCH channel: PUCCH format 0 over 1-2 OFDM symbols once per slot with FH

by Q219 by Q219

Latenc y
Latenc y
Latenc y
Latenc y

Uplink DMRS for scheduling type A, support 2 symbols FLDMRS Uplink DMRS for scheduling type A, support 1 symbol FL DMRS without additional symbol(s) Downlink DMRS for scheduling type A, support 2 symbols FLDMRS Downlink DMRS for scheduling type A

Uplink DMRS for scheduling type A, support 2 symbols FL-DMRS
The UE shall support Uplink DMRS for scheduling type A, support 1 symbol FL DMRS without additional symbol(s)
The UE shall support Downlink DMRS for scheduling type A, support of 2 symbols FL-DMRS
The UE shall support Downlink DMRS for scheduling type A, support of 1 symbol FL DMRS without additional symbol(s)

by Q219 by Q219 by Q219 by Q219

Latenc y
Latenc y

Non-slot feature: PDSCH mapping type A Non-slots feature: Timedomain resource allocation

The UE shall support Non-slot feature: by Q219 PDSCH mapping type A with less than 7 OFDM symbols

The UE shall support Non-slots feature: Time-domain resource allocation - 1-14 OFDM symbols for PUSCH once per slot - Starting symbol, and duration are determined by using the DCI - PDSCH mapping type A with 7-14 OFDM symbols - PUSCH mapping type A and type B - For type 1 without dedicated RRC configuration and for type 0, 0A, and 2, PDSCH mapping type A with {4-14} OFDM symbols and type B with {2, 4, 7} OFDM symbols (this last point required with the Ue supports SA)

by Q219

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306
3GPP TS 38.306

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

General Requirements

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide Area Connect ivity

General Requirements

Latenc Non-slots: less

y

than 7 OFDM

symbols

5G NR PDCCH case 2

The device shall support Time-domain resource allocation - PDSCH mapping type A with less than 7 OFDM symbols
Support Case 2: PDCCH monitoring periodicity of less than 14 symbols

by Q219 by Q219

3GPP TS 38.306
3GPP TS 38.306

UL Carrier Aggre gation
UL Carrier Aggre gation
UL Carrier Aggre gation
Massiv e MIMO
UI
Dual Conne ctivity - 2 Bands + SDL InterB and EN-DC within FR1 Dual Conne ctivity - 2 Bands InterB and EN-DC within FR1 VVS Refere nce

CA_1A-28A UL
CA_20A-38A UL CA_3A-38A UL
FDD + TDD DL CA for TM2, TM3 and TM4 with FDD as Pcell Technology selection
DC_20A_n75/ 76-n78A
DC_1A_n28A
VVS Reference

All UEs of Cat 6 or higher have to support CA in UL band 1 (2100) + band 28 (700) bandwidth B1 (10-20 MHz) , B28 (1015 MHz) All UEs of Cat 6 or higher have to support CA in UL band 20 (800) + band 38 (2600 TDD) (min bandwidth 10 MHz + 15MHz; max bandwidth 10MHz + 20MHz) All UEs of Cat 6 or higher have to support CA in UL band 3 (1800) + band 38 (2600 TDD) (min bandwidth 10 MHz + 15MHz; max bandwidth 20MHz + 20MHz) Support for FDD + TDD DL CA for TDD in TM2, TM3 and TM4 being FDD set as Pcell. The vendor shall specify the supported band configurations if not band agnostic. Specific combos required for FDD+TDD defined in separate TCDs The UE user interface shall present the user with configuration options to select the radio access technology to be used from the following when these are supported by the terminal: 2G, 3G, 4G, 5G Support of Dual connectivity with Supplementary Downlink (SDL) between the specified 1 LTE carriers + 2 5G NR carrier up to 130 MHz, with detailed bandwidth granularity. Min BW: 10+20+100 Max BW: 10+15+20
Support of Dual connectivity between the specified 1 LTE carrier + 1 5G NR carrier up to 20 MHz, with detailed bandwidth granularity. DC_1A_n28A combination Min BW: 10+10 Max BW: 10+10
Terminal shall support the country specific settings for the service configuration and correct operation on Vodafone network. Afore mentioned settings can be access using the latest version of VVS (Vodafone Variant Setting repository)

Important to support higher data rate in UL By 2H18 for NZ Resquested for MaMIMO when the Pcell is in the PCC to increase peak rate in the UL Resquested for MaMIMO when the Pcell is in the PCC to increase peak rate in the UL Now
Allow user to manually switch technology
By 1H20 for VF UK Requested for UK
By 2H20 for UK and DE

3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
ongoing in 3GPP
3GPP TS 38.1013, Rel15, section 5.5B.4.1
VVS: ##insert VVS database hyperlin k for OEMs##

##insert VVS database hyperlink for

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

OEMs##

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

General Requirements

Spectr um sharin g: 3G4G or 2G-4G Spectr um sharin g: 3G4G or 2G-4G
Locati on
Locati on
Latenc y
Latenc y
Compl iance with 3GPP specifi

PUCCH allocation
Partial RB set measurements
Indoor positioning enhancements - Others (Rel13) Indoor positioning enhancements - WiFi (Rel-13) 1 ms TTI for FDD and TDD Rel-15 latency improvements
2 symbols TTI
Maintenance of future compatibility Abuse of spare bits in MIB

(note: in case you do not have access, please request it to your Vodafone counterpart) In case some settings cannot be supported or configured country per country: please state all limitations in the comment section Support for on-sided PUCCH allocation to allow configuration of PUCCH resources only one side of the 4G spectrum allocation (as opposed to typical edge PUCCH RB allocation on both sides of the spectrum Support for allowed measurement bandwidth to control the UE RB set over which the UE performs its mobility measurement (RSRP and RSRQ). UE shall be able to carry out mobility measurements over 6, 15, 25, 50, 75, 100 RB´s according to IE AllowedMeasBandwidth as per 3GPP TS 36.331. The vendor shall explicitly state compliance for all values (all values supported or subset) The vendor shall provide following additional information: 1) The vendor shall explicitly state whether RSRP UE measurements reports are based on a reduced transmission bandwidth in non-muted RB's. 2) The vendor shall explicitly state whether RSRQ UE measurements reports are based on a reduced transmission bandwidth in non-muted RB's. The UE shall support Bluetooth, barometric and proprietary Beacon System measurements defined to assist control plane UE positioning (LPP) as specified in Rel-13. UE-based methods are included. The UE shall support WiFi measurements defined to assist control plane UE positioning (LPP) as specified in Rel-13. UE-based methods are included. Support the improvements being standardised in 3GPP for the 1 ms TTI for 4G
2 symbols TTI according to 3GPP Rel15 for all FDD 4G carriers
Terminal software shall not be implemented such that spare bits in Master Information Block are assumed to be set to zero values. Failure to comply with this requirement would

Not defined
By now
Improves location accuracy when out of coverage of satellite based system.
Improves location accuracy when out of coverage of satellite based system.
By 2Q19 3GPP Rel-15 will improve the latency, and it is quite important the industry is adopting them tentative by 4Q18 as earliest Latency is one of the key factors to enhance the User Experience, and now the current RTT measurements are between 20 and 40 ms Required for 2Q19 Latency is one of the key factors to enhance the User Experience, and now the current RTT measurements are between 20 and 40 ms Essential to ensure that terminals continue to function correctly after infrastructure upgrade. Incorrect implementation can result in loss of network coverage

3GPP TS 36.331
3GPP TS 36.455
3GPP TS 36.455 3GPP TS 36.133 Rel-15
3GPP TS 36.133 Rel-15 N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

Wide

5G

Area

Connect

ivity

cation s
RRC RRC States States

mean that future use of these spare bits causes potential incorrect behaviour.

An example of this would be the introduction of additional functionality in 3GPP Rel. 13 to support LTE Cat-M where the previously spare bits are now used to indicate eMTC is supported in the cell The device shall support RRC States of connected, idle according to 3GPP definition

By Q219 (now for testing)

Dual conne ctivity UL
Dual conne ctivity UL
Dual conne ctivity UL
Dual Conne ctivity - 5 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 4 Bands InterB and EN-DC within FR1 Dual Conne ctivity - 5 Bands InterB and EN-DC within FR1

Reconfiguratio n single - dual UL frequency
Single frequency UL operation Normal 5G NR UL operation
DC_1A-3A-7A28A_n78A
DC_3C-7A20A_n78A
DC_1A-3A-7A20A_n78A

The device shall support the reconfiguration from single UL frequency operation to dual frequency operation based e.g. on coverage conditions or latency necessities for a single UE The device shall support in Dual Connectivity connection, the operation in single UL frequency where LTE UL and NR UL share the same UL frequency band The device shall support in Dual Connectivity connection, the operation in dual UL frequency where LTE UL and NR UL have different UL frequencies for a single UE, and NR UL is transmitted using the 5G NR frequency band Support of Dual Connectivity between the specified 4 LTE carriers + 1 5G NR carrier up to 170MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 3DL, 2DL or 1DL (+ 5G NR) DC_1A-3A-7A-28A_n78A combination Min BW: 5+5+15+15+20 Max BW: 5+20+15+15+100
Support of Dual connectivity between the specified 4 LTE carriers + 1 5G NR carrier up to 170MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 3DL, 2DL or 1DL (+ 5G NR) DC_3C-7A-20A_n78A contiguous Min BW: 20+5+20+10+20 Max BW: 20+10+20+10+100
Support of Dual Connectivity between the specified 4 LTE carriers + 1 5G NR carrier up to 170MHz, with detailed bandwidth granularity. LTE would be with fallbacks to 3DL, 2DL or 1DL (+ 5G NR) DC_1A-3A-7A-20A_n78A combination Min BW: 5+5+20+10+20 Max BW: 15+20+20+10+100

By Q219 (now for testing) By Q219 (now for testing) By Q219 (now for testing) By 2H19 for NZ and by 2H20 for MT
By 2H19 for DE
Most common for Europe and AMAP By 2Q19 for ES, DE and IT

3GPP TS 38.1013, Rel15, section 5.5B.4.4
Configur ation not in 3GPP 15.2.0
3GPP TS 38.1013, Rel15, section 5.5B.4.4

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) UL Carrier Aggre gation
UL Carrier Aggre gation
UL Carrier Aggre gation
UL Carrier Aggre gation
UL Carrier Aggre gation
UL Carrier Aggre gation
UL Carrier Aggre gation

CA_1A-3A-41A DL
CA_3A-3A-41A DL
CA_1A-41A DL

All UEs of Cat 9 or higher shall support downlink CA band 1 (2100) + band 3 (1800) + band 41 (2500 TDD) combination: (min bandwidth 3 MHz + 3 MHz + 10 MHz; max bandwidth 20MHz + 20 MHz + 10 MHz) All UE of Cat 9 or higher shall support downlink CA band 3 (1800) + band 3 (1800) + band 41 (2500 TDD) combination, using non contiguous bands: (min bandwidth 3 MHz + 5 MHz + 10 MHz; max bandwidth 20MHz + 20 MHz + 10 MHz) All UEs of Cat 6 or higher have to support downlink CA band 1 (2100) + band 41 (2500 TDD) combination: (min bandwidth 3 MHz + 10 MHz; max bandwidth 20 MHz + 20 MHz)

CA_3A-41A DL

All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 41 (2500 TDD) combination: (min bandwidth 3 MHz + 10 MHz; max bandwidth 20 MHz + 20 MHz)

CA_7A-20A UL CA_1A-20A UL CA_1A-3A UL CA_7A-28A UL CA_3A-28A UL CA_3C UL CA_3A-7A UL

All UEs of Cat 6 or higher have to support CA in UL band 7 (2600) + band 20 (800) (min bandwith 5 MHz + 10MHz; max bandwith 20MHz + 20MHz) All UEs of Cat 6 or higher have to support CA in UL band 1 (2100) + band 20 (800) (min bandwidth 5 MHz + 10MHz; max bandwidth 20MHz + 20MHz) All UEs of Cat 6 or higher have to support CA in UL band 1 (2100) + band 3 (1800) (min bandwidth 5 MHz + 5MHz; max bandwidth 20MHz + 20MHz) All UEs of Cat 6 or higher have to support CA in UL band 7 (2600) + band 28 (700) (min bandwidth 15 MHz + 15MHz; max bandwidth 15MHz + 15MHz) All UEs of Cat 6 or higher have to support CA in UL band 3 (1800) + band 28 (700) (min bandwidth 5 MHz + 15MHz; max bandwidth 20MHz + 15MHz) All UEs of Cat 6 or higher have to support CA in UL band 3 (1800) + band 3 (1800) (min bandwidth 20 MHz + 5MHz; max bandwidth 20MHz + 15MHz) All UEs of Cat 6 or higher have to support CA in UL band 3 (1800) + band 7 (2600) (min bandwidth 5 MHz + 20MHz; max bandwidth 20MHz + 10MHz)

Essential to ensure sufficient bandwidth for acceptable data rates: India in 2H 2017
Essential to ensure sufficient bandwidth for acceptable data rates: India in 2H 2017
Essential to ensure sufficient bandwidth for acceptable data rates for Vodafone India
Essential to ensure sufficient bandwidth for acceptable data rates for Vodafone India
Important to support higher data rates in the Uplink Support requested by 1H17 in NZ and later in EU
Important to support higher data rates in the uplink Support requested by 1H17 in EU (Spain and UK), AMAP
Important to support higher data rates in the uplink Support requested by 1H17 in EU, AMAP and IE
Important to support higher data rates in the Uplink Support requested by 1H17 in NZ and later in EU
Important to support higher data rates in the Uplink Support requested by 1H17 in NZ and later in EU
Important to support higher data rates in the Uplink Support requested by 1H17 in EU(Romania, DE) and Australia
Important to support higher data rates in the Uplink Support requested by 2H16 in EU

> 5Mhz Rel-14 3GPP TS 36.101 < 5MHz not yet in 3GPP 3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101 Rel-14
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

UL Carrier Aggre gation Speed
Locati on

CA_3A-20A UL
UL Compression 4G
UE Rx-Tx time difference measurements

All UEs of Cat 6 or higher have to support CA in UL band 3 (1800) + band 20 (800) (min bandwidth 5 MHz + 10MHz; max bandwidth 20MHz + 10MHz) Lossless compression of UL payload and headers in the device for 4G
UE Rx-Tx time difference measurements according to TS 25.331.

Important to support higher data rates in the Uplink. Support requested by 2H16 in EU and Qatar
Improved UL data throughput and power consumption, important mainly for congested scenarios as hot spots, big events... with high UL bottleneck. Planned in all market stating since 2H16. Benefits: - Reduced Battery consumption. - Increased Capacity and coverage of a cell. - More available resources - Improved inter active response time results Required for Location Based Services planned to implement across Vodafone Group by 2017

3GPP TS 36.101 N/A
3GPP TS 25.331.

Locati on
Locati on

Timing Advance Information Type 1
UTDOA Rel-12

Latenc 7 symbols TTI y

Interfe rence Manag ement

PDSCH-IC

Interfe rence Manag ement

CRS-IC

The eNB will request the Timing Advance Information Type 1 of every UE according to TS 36.214.
The UE will support the UTDOA as specified in 3GPP Rel-12. Positioning based on time difference between uplink signals
7 symbols TTI according to 3GPP Rel15 for all FDD 4G carriers and TDD 4G carriers
Cancellation or Suppression as defined in 3GPP Rel-12, using information about its most relevant interferers to substantially improve demodulation performance in presence of PDSCH interference from neighbour cells.
Cancellation or Suppression as defined in 3GPP using information about its most relevant interferers to substantially improve demodulation performance in presence of CRS interference from neighbour cells.

Required for Location Based Services planned to implement across Vodafone Group by 2017
Optional feature, requested for information, due to no high priority for deployment. This feature enhances the accuracy of UTDOA. By 2Q19 Latency is one of the key factors to enhance the User Experience, and now the current RTT measurements are between 20 and 40 ms. Previous TCD-BEAR-REQ-012175 requirement.
Needed specify the method to support that: - Network Assisted IC - Standalone - Both (Nw assisted + Standalone) Previous TCD-BEAR-REQ-012175 requirement.
Needed specify the method to support that: - Network Assisted IC - Standalone - Both (Nw assisted + Standalone)

3GPP TS 36.214
3GPP TS 25.305, Rel-12 3GPP TS 25 3GPP TS 36.133 Rel-15
3GPP TS 36.300 Rel-12 and TS 36.331 Rel-12
3GPP TS 36.300 and 3GPP TS 36.331

4 Carrier Aggre gation (Multi Band)

CA_1A-7A20A-32A DL

All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 7 (2600) + band 20 (800) + band 32 (1400) combination: (min bandwidth 5 MHz + 20 MHz + 10MHz + 20 MHz; max bandwidth 15 MHz + 20MHz + 10MHz + 20MHz)

Specify the Release supported (Rel11, Rel-12 or Rel-13) Important to support higher data rates in the Downlink. Support requested by 2H17 in DE, IT, UK

3GPP TS 36.101

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

UMTS

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

4 Carrier Aggre gation (Multi Band)
4 Carrier Aggre gation (Multi Band)
HSPA Evoluti on
Speed
4 Carrier Aggre gation (Multi Band)
4 Carrier Aggre gation (Multi band)
3 Carrier Aggre gation (Multi Band)
3 Carrier Aggre gation (Multi Band)
Locati on

CA_1A-3A-7A20A DL
CA_3C-7A-32A DL
3G->4G reselection on Cell FACH State Downlink 256QAM - LTE
CA_3A-7A20A-32A DL
CA_3C-20A32A DL
CA_3A-7A-38A DL
CA_1A-3A-20A DL
MDT - Idle mode (Logged)

All UEs of Cat 11 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 7 (2600) + band 20 (800) combination: (min bandwidth 5 MHz + 5 MHz + 20MHz + 10 MHz; max bandwidth 15 MHz + 20MHz + 20MHz + 10MHz) All UEs of Cat11 or higher have to support downlink CA band 3 (1800) + band 3 (1800) + band 7 (2600) + band 32 (1400) combination: (min bandwidth 20MHz + 5 MHz + 20 MHz + 20MHz; max bandwidth 20 MHz + 10MHz + 20MHz + 20 Mhz) UE requirement to support mobility from CELL_FACH to E-UTRA RRC_IDLE as defined in the 3GPP TS 36.331 from Rel-11. Possible to implement functionality from Rel-8 UEs onwards. 256QAM should be with 4Rx in connected mode. Required support in all carriers when Carrier Aggregation is in place. 256QAM DL should be supported for TM2, TM3, TM4, TM7, TM8 and TM9 any release. Starting 2017/18 all UEs of Cat 11 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 20 (800) + band 32 (1400) combination: (min bandwidth: 5MHz + 20MHz + 10MHz + 20MHz, max bandwidth: 20 MHz + 20 MHz + 10 MHz + 20 MHz) All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 20 (800) + band 32 (1400) combination: Bandwidth: (20 MHz -lower carrier + 5 MHz -higher carrier) + 10 MHz + 20 MHz All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 38 (2600 TDD): (min bandwidth 20 MHz + 20 MHz + 20 MHz; max bandwidth 10 MHz + 20 MHz + 20 MHz) All UEs of Cat 9 or higher have to support downlink CA band 1 (2100) + band 3 (1800) + band 20 (800): (min bandwidth 5 MHz + 5 MHz + 10 MHz; max bandwidth 20 MHz + 20 MHz + 10 MHz) Support of Logged MDT (Minimization of Drivetests) procedures according to the 3GPP TS 37.320, chapter 5.1.1. to obtain all information: · time stamp · serving cell ID · serving cell measurements (RSRP, RSRQ) · neighbor cell measurements (RSRP, RSRQ, RSCP, Ec/N0, RxLev,...)

Important to support higher data rates in the Downlink. Support requested by 2H16 in UE
Important to support higher data rates in the Downlink. Support requested for EU by 1H17. Prio for VFDE
Relevant for all LTE devices. Useful to accelerate the reselection to LTE while in 3G data connection. Network readiness since 3Q15 Essential feature to improve the DL user throughput. Expected deployment in 3Q16 in all markets.
Important to support higher data rates in the Downlink. In Greece by 2H20.
Important to support higher data rates in the Downlink in Europe, in first step for the OpCos with B32 assigned DE and IT. In plan for 1H17
Important to support higher data rates in the Downlink in Europe. Support requested by 1H17
Important to support higher data rates in the Downlink in Europe. Support requested by 1H16
requested for deployment for 2H16.

3GPP TS 36.101
3GPP TS 36.101
N/A
N/A
N/A
N/A
3GPP TS 36.101
3GPP TS 36.101
3GPP TS 37.320 3GPP TS 36.214

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Locati Validity Time

on

<= 10secs

eMBM S

MBMS interfrequency service awareness

eMBM S

MBMS counting of UEs

eMBM SIB15 S

eMBM S

MBMS service interest indication

· GNSS location (Standalone UE GPS)

according to the TS 36.331 Release if

available by the UE when taking the

measurement

· Timing Advance according to TS

36.214.

If there is any parameter not reported

in the MDT logs please specify it.

Vendor should specify if there is any

limit in logging time.

If there is any limit on number of users

please specify it.

Validity timer is used in order to

Non homogeneous behaviour of

N/A

consider that a location measurement different device as far as the

taken by the UE in the past is still valid. reliability of the location information

The timer value is actually set by the provided by the UE to the NW

UE and is not controlled (as many other

timers) from the NW.

We set here a range of values we do

consider acceptable

Informing UEs when there is an MBMS eMBMS consumes NW resources, so N/A

service available on another frequency it won't be set-up in all the LTE

(as opposed to it having dual frequency frequencies/layers of a sector, but

reception capabilities like in Rel-10)

only on (e.g.) 1 of them

Such a capability allow to notify a UE

camped on (e.g.) f2 that EMBMS is

available in f1, so the UE can change

frequency and camp on the one with

eMBMS service available

Indication to inform network that the Needed in order to avoid consuming N/A

UE is receiving an MBMS service(s) to common channels and resources for

allow it to decide whether PTM is useful eMBMS when the number of UEs

or if unicast is best.

willing to receive data from a specific

eMBMS channel is low and doesn't

justify maintaining the usage of the

eMBMS transmission for that specific

service

UE support the reading of SIB15, useful Improvement in the signalling in

N/A

for eMBMS operation

eMBMS that allow introduction of

eMBMS enhancement as service

continuity TCD-BEAR-REQ-012093 or

multiple carriers

Allows UE on f1 to indicate that it

Needed for eMBMS launch

N/A

wishes to receive MBMS being sent on

f2.

eMBM Basic MBMS MBSFN operation requiring network

Needed for eMBMS launch

N/A

S

introduction sync

for SFN

operation

eMBM eMBMS S

eMBMS support

Needed for eMBMS launch

N/A

Advan 3 or 4 Way RX Support of 3 or 4 way RX diversity in the Important increase of performances N/A

ced diversity

terminal

in the downlink just due to the

Receiv

receiver side

er

Techn

ologie

s

Advan IRC receiver Support of Interference Rejection

Important increase of performances N/A

ced

Combining and, in general, advanced in the downlink just due to the

Receiv

receivers

receiver side

er

Techn

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service
ologie s

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Hetero geneo us Netwo rks
Gener al
3 Carrier Aggre gation (Multi Band)
Gener al

Cross carrier scheduling
TM10
CA_3A-7A-28A DL
4G Device Behaviour

3GPP Rel-10 feature In HetNet deployment where same frequency band is being deployed in both macro and small cells, Carrier Aggregation with CA capable terminals using cross carrier scheduling will provide a higher degree of gain as CA users will be able to avoid interference in control regions The UE shall support Transmission Mode 10 (TM10)
All UEs of Cat 9 or higher have to support downlink CA band 3 (1800) + band 7 (2600) + band 28 (700APAC) combination: min bandwidth 5 MHz + 15 MHz + 15 MHz; max bandwidth 20 MHz + 20 MHz + 15 MHz When the UE receives a Combined Attach or TAU accept for EPS services only with cause #16, #17 or #22, the UE will disable 4G and reselect to 2G or 3G as per 3GPP 24.301. The UE must enable 4G again within 20 minutes so that the UE is ready to perform a cell reselection or PS Handover back to 4G. 4G must be re-enabled without interrupting any on-going data transfer; if the enabling of 4G requires loss of data connectivity, then on expiry of the timer the UE should only enable 4G if in PCH or Idle state. The UE must not wait until the device is down-switched to idle by the NW before re-enabling 4G.

Improved NW performance in terms of resource management consumption as well as higher throughput available to the end user
Needed in order to support: - Coordinated Scheduling improvements (for both non-ideal and ideal backhaul scenarios) and Dynamic Point Selection (ideal backhaul scenarios e.g. intra-eNB or C-RAN) and. Joint Transmission support is low priority as benefits are expected to be lower. - SFN nw vendor improvements, in which different adjacent cells support the same frequencies. Need to specify the 3GPP Rel supported. Important to support higher data rates in the Downlink. In New Zeland available now.
To ensure that 4G is reconnected once available again.

3GPP TS 36.212
3GPP TS 36.213
3GPP TS 36.101
3GPP TS 24.301

Wide Area Connect ivity

LTE - Voice and Messaging

USSD CSFB for IMS via IMS USSD

Note: The timer T3402 (default 12 minutes) could be used to determine when to enable 4G again. In case the VoLTE capable UE does not support Unstructured Supplementary Service Data (USSD) via IMS according to 3GPP TS 24.390 Rel.11, the UE shall perform CSFB including extended service request in order to allow USSD in VoLTE domain. Also SCI (subscriber controlled input, e.g. *21#) shall be supported by the UE.

Important to improve battery lifetime 3GPP TS 23.272

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity

General Requirements

SON
SON
SON
Power Manag ement
Conne cted Mode Mobilit y Uplink
Gener al

MDT (Minimization of Drive Tests LTE) RACH optimisation
SON
eMBMS - ESPSM
Intrafrequency PS Handover
High Order Modulation
CoOrdinated Multi Point (CoMP)

The device shall support measurements for MDT (Minimization of Drivetests) as defined in 3GPP TS 37.320, up to Rel-13
The device shall support measurements for RACH Optimisation as defined in 3GPP 36.300 subsection 22.4.3.
The device shall support the necessary functions to enable the Self Configuration and Optimisation (SON) capabilities described in 3GPP TS 36.300, subsection 22 The UE shall support eMBMS in order to support "Enhanced Symbol Power Saving Mode". In case the UE does not support eMBMs it shall ignore the eMBMS TTI , also in combination with MBSFN . The UE needs to support intrafrequency PS handover across the necessary frequency bands for service continuity.
64QAM support
Intra/Inter eNB Joint Transmission

Essential for all LTE terminals - allows networks to self organise
Essential for all LTE terminals - allows networks to self organise
Essential for all LTE terminals - allows networks to self organise. Rollout of SON features are being implemented in our LTE networks today. Important to improve battery lifetime
Essential standards compliance baseline for all LTE terminals
Important to support higher data rates in the Uplink. 64QAM should be supported in all the component carriers when in CA or when the UE is registered in MaMIMO cell.
Important to support higher data rates in the Downlink

N/A
N/A
N/A
3GPP 23.246 (Rel-9)
N/A
3GPP TS 36.306, and tables 4.1.1, 4.1.2 and 4.1.3 3GPP TS 36.306

Hetero geneo us Netwo rks
2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) 2 Carrier Aggre gation (Multi Band) UI

eICIC
CA_7A-20A DL
CA_3A-20A DL
CA_3A-7A DL
Data connection set up wizard

The device shall support TDM based enhanced ICIC (eICIC)as defined in 3GPP TS36.300 and 3GPP TS36.331 including; Advanced receiver capability Almost Blank Subframes (ABS) Cell Range Expansion (CRE) All UEs of Cat 6 or higher have to support downlink CA band 7 (2600) + band 20 (800) combination: (min bandwidth 20 MHz + 10 MHz; max bandwidth 20 MHz + 10 MHz)
All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 20 (800) combination: (min bandwidth 5 MHz + 10 MHz ; max bandwidth 20 MHz + 10 MHz )
All UEs of Cat 6 or higher have to support downlink CA band 3 (1800) + band 7 (2600) combination: (min bandwidth 5 MHz + 20 MHz; max bandwidth 20 MHz + 20MHz)
1. Device should offer a data connection set up wizard 2. Data set up wizard should be available at first device start up 3. Device should not send any data

Essential for all LTE terminals - allows to efficiently deploy different cell layers within the network

3GPP TS 36.300 and 3GPP TS 36.331

Support for current network deployment

3GPP TS 36.101

Support for current network deployment (EU, Qatar).Already rolled out.

3GPP TS 36.101

Support for current network deployment

3GPP TS 36.101

Customer must be able to set and

N/A

modify his/her data connection

preferences

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide Area Connect ivity
Wide Area Connect ivity Wide Area Connect ivity
Wide Area Connect ivity Wide Area Connect ivity
Wide Area Connect ivity Wide Area Connect ivity
Wide Area Connect ivity
Wide Area Connect ivity

LTE LTE UMTS UMTS LTE LTE - Voice and Messaging LTE - Voice and Messaging UMTS
UMTS

Gener Default Bearer

al

Modification

Gener Radio Link

al

Failure Report

Gener UMTS Bands II

al

(1900MHz)

Gener UMTS Bands V

al

(850MHz)

SON
SMS via IMS

ANR Automatic Neighbor Relationship for Inter-RAT Connected DRX - LTE

SMS SMS over IP via IMS

Home VAP Reject#13 NodeB Forbidden LAC
list

Home VAP Operator NodeB logo

before the customer has defined data connection settings 4. Data settings can be modified by end user at any time 5. User should be notified that data traffic is disabled if attempting to use a service that requires data connectivity After the default bearer has been setup, it might be necessary to establish a redirect to html landing page. This will be realised by assigning or modifying the TFT of the default bearer context. The UE shall send RLF (Radio Link Failure) Reports for Radio Optimisation according to 3GPP TS 36.331
Support for UMTS 1900 shall be as described in 3GPP 25.816, optional for roaming purposed.
Support for UMTS 850 shall be as described in 3GPP 25.816, required for products in VHA, Australia.
The device shall support measurements for ANR - Automatic Neighbor Relationship as defined in 3GPP 36.300 for Inter-RAT 2G, 3G, LTE.
The VoLTE capable device shall support connected mode DRX
The VoLTE capable device shall support SMS over IP according to 3GPP TS 24.341. (The UE shall treat all Applications and SMS content bearer agnostic (e. g. Config-SMS, Push-SMS, Zero-SMS,...) regardless the transport layer used (MAP, NAS or IP) Only applicable to 3G devices When the UE tries to camp or reselect from the standard macro network (either 2G or 3G) to a femtocell (radiating in a different frequency than the standard one and with different Location & Routing Area Codes) and it is rejected by the femtocell using Location / Routing Area Update Reject with reject cause #13 (Roaming not allowed in this location area), the UE shall follow the procedure specified in 3GPP TS 24.008, Rel-8 section 4.4.4.7. Terminal with SIM provisioned in VAP service (femtocell) must display OpCo VAP operator name instead of macro OpCo name in IDLE state. According to 3GPP TS 22.042 Section 6.1 `Network name, time, DST and timezone information can be transferred from the serving PLMN to the MS: ... 4) When the network changes its identity. And Section 6.2: It is expected that the MS will display the most up to date

Essential for all LTE devices in order to allow redirect to html landing page, e.g. in case of throttling.
This is relevant for all device types. This feature is important for network optimisation.
Will impact roaming to North America for 3G devices - This is Essential for Enterprise devices, but less important for Consumer devices (particularly in the low tier) Essential for products in VHA, Australia
Essential for all LTE terminals - allows networks to self organise
Essential for all VoLTE terminals in order to allow power saving.
Essential to provide messaging solution for LTE terminals
Required for support of Femto deployments. As Femtocells are now extensively deployed in Vodafone OpCos, it is essential that this is supported
Needed to support femtocell strategy. Allows user to easily see whether he is using femto or macro network

3GPP TS 24.301 3GPP TS 36.331 N/A N/A N/A N/A N/A
N/A
N/A

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework

Vodafone Group Products & Service

Wide

LTE

Area

Connect

ivity

Wide Area Connect ivity
Wide Area Connect ivity

LTE UMTS

Wide Area Connect ivity

UMTS

Wide Area Connect ivity

General Requirements

information transferred to it.'

The name to be displayed in sent

during macro cell or femtocall GPRS

attach procedure within the GMM

information message.

The UE shall always display the last

operator name that has been received.

SON ANR -

The device shall support

Essential for all LTE terminals - allows N/A

Automatic

measurements for ANR - Automatic

networks to self organise

Neighbor

Neighbor Relationship as defined in

Relationship 3GPP TS 36.300 for Intra-LTE.

for Intra-LTE

SMS SMS via SGs The device shall support SMS via SGs as Essential for LTE Smartphones -

N/A

defined in 3GPP 23.272.

provides messaging solution if no

IMS based SMS is available

HSUP A
Gener al
Regula tions

UE Uplink Category
UMTS Band VIII (900MHz)
GCF Certification and test results

The UE capability supported for HSUPA shall be Category 6 minimum, with Category 8 being preferred. Cat 7 is not preferred as strategy is to deploy Cat 8 support in our networks.
Support for UMTS 900 shall be as described in 3GPP 25.816.
The device shall be GCF Certified. The applicable GCF release will be the due one at the date of the Vodafone 's qualification.

Determines Uplink data throughput Essential for UMTS terminals Cat 8 uplink capability is essential for high tier smartphones and other devices with higher data rate capabilities Dependant on the support of UMTS 900 - as specified in the RFP. UMTS 2100 is mandatory for all OpCos and UMTS900 is now widely used in many OpCos too Device will NOT fulfil legal requirements for approval of a wireless device.

N/A
N/A
GCF Certifica tion

All applicable current Performance criteria defined in GCF PC shall be provided to Vodafone at the start of the acceptance testing.

C2 General

V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework


Microsoft Word 2016 Microsoft Word 2016