Vodafone Group Products & Services Release 2019 – V1.0 © Vodafone | Extract Vodafone Device Requirements and Compliance Framework C2 General
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