SUPPLY AND/OR INSTALLATION, TESTING,

COMMISSIONING & INTEGRATION OF NB-IOT

BASED GATEWAYS FOR SMART METERING
PROJECT

Scope of Work (Turnkey)

The bidder shall undertake supply, installation, integration, testing and

commissioning of NB-IoT gateways, based on demand. The bidder shall
provide the following scope, but not limited to:
1) Supply of the Gateways.
2) Site surveys.
3) Gateway installation (including cabling between meters and
gateways), related accessories and integration with meters.
4) Integration with Client network and AMI platform hosted on
Client Cloud.
5) Gateway configuration.
6) Gateway testing.
7) Commissioning, training and handing over
The gateways shall support the following deployment scenarios:
Requirement Detail
One gateway to integrate a single meter, meant for
1:1
scenarios like bulk meters, street light meters, etc.
One gateway to integrate one Electricity meter and
1:2
one Water meter, meant for villas.
Meters One gateway to integrate multiple Electricity or
Integration 1:Many Water meters, meant for buildings or other locations
with many meters.
Bulk Bulk Metering for water meters
Legacy Euridis, Severn Trent, Others (apart from standard
Protocols protocols, as mentioned overall in previous sections)
Platform
Protocols MQTT, CoAP, sFTP
Integration
Simple IP data relay from IP devices (like PLCs,
Substations IP:IP
RTUs) to a SCADA system
Please provide the following details related to offered solution:
1. The current Hardware (HW) / Software (SW) release that was first made
available for live deployment.
2. Provide a roadmap for product with versions, release schedules and
description of planned/anticipated additional features and
functionalities.
3. The product specification datasheet shall be submitted with the following
(but not limited to):
a. Detailed technical specifications including capacity, power
consumption and key components such as interface details,
processing power, scalability etc.
b. Original Manufacturer product datasheet.
c. Country of manufacture/origin.
d. Model/part number.
BOQ
The Bidder shall submit their offers in excel format as per the below table
& attached BOQ format:
Manufacturer
Name/
S/N Item Description UOM Unit Price
Country of
Origin
1. Product
1.1 NB-IoT Gateways
Accessories,
Cabling, and
1.2
other passive
material
1.3 Enclosure
2. Installation
1:1
Installation,
1:2
Integration,
2.1
Commissioning, 1:Many
and Testing Bulk(Water
meter)
3. Optional items
External
3.1 Antennas
(Optional)
3.2 Power Tapping
3.3 others
TECHNICAL REQUIREMENTS

1. The bidder shall complete the scope of this TENDER in line with the
required functionalities and specifications.
2. The proposed NB-IoT based gateways shall support the following (but not
limited to) protocols towards the sensors:
a. DLMS
b. MBus
c. Wireless Mbus
d. Euridis
e. Severn Trent
f. Modbus
g. Pulse
h. Bluetooth
i. ZigBee
j. Wi-Fi
k. Any others
1. The bidder shall be responsible for any development and customization
works, which might be required for integrating other non-standard
protocols in the existing meters.
2. Gateways shall be able to receive PKI certificates and use them for data
encryption and communication.
3. The bidder to provide how to manage implementation of unique OTPs
using KMS and/or unique passwords.
4. The gateways minimum IP 55 Rating
5. The bidder to provide Security Sealing
6. The gateway to have a battery for back up for at least 1 hour (optional
component)
7. The bidder to provided Withstand surges and voltage spikes of 6 KV as
per IEC 610000-4-5 Standards
8. The bidder shall confirm the interoperability of different meter protocols
within the same Gateway
9. The gateways shall be able to integrate with electricity smart meters from
but not limited to Actaris, Elster, and Iskraemeco. Additionally, the
 bidder shall also list all the electricity meters’ manufacturers/models the
proposed gateways are compatible with.
10. The gateways shall be able to integrate with water smart meters from
but not limited to Hydrus, Elster, Itron and Severn Trent. Additionally,
the bidder shall also list all the water meters’ manufacturers/models the
proposed gateways are compatible with. The gateways are required to
communicate over the NB-IoT network for transmission of data. The
modulation should achieve minimum data packet sizes to keep the data
volume at minimum.
11. The gateways are required to communicate the data to Etisalat’s
Advanced Metering Infrastructure (AMI) platform hosted on Etisalat
cloud. The protocol to be followed is MQTT and CoAP – MQTT for
asynchronous and CoAP for synchronous data transmission. The
modulation should achieve minimum data packet sizes to keep the data
volume at minimum.
12. Furthermore, the gateway should comply with security encryption and
capable of working with PKI/HSM/KMS for encryption.
13. Preferably, the proposed gateways shall be universal type, and software
configurable, and the installation/replacement of the gateways shall be
possible without any customization/development works from the
manufacturer.
14. Durability and signal power shall be able to penetrate manholes.
15. The minimum Rx Sensitivity shall be -140 dBm.
16. The data rates shall be 25kbps in DL, and 60Kbps in UL (multitone).
However, the bidder may propose the DL and UL capabilities of their
proposed gateway.
17. The Tx Power shall be 20 or 23 dBm. However, 14 dBm can be considered
for specific outdoor cases.
18. The NB-IoT gateways shall support Guard band, In-band and
Standalone deployment modes. The supported bands shall be B3, B8,
B20, B28.
19. The NB-IOT gateways shall support the external antenna. However, the
bidder shall optionally quote (separately) for external antenna.
20. The NB-IoT gateways shall have the following features:
4.20.1 Power saving mode (PSM)
4.20.2 eDRX
4.20.3 CP based EPS optimization
4.20.4 Cell reselection
4.20.5 Extended coverage levels (ECL0 / ECL1 / ECL2)
 4.20.6 Both Single tone and multi-tone support
4.20.7 Multi tone with SCS bandwidth of 3.75 up to 15 Khz per tone
4.20.8 Rel-13 Compliant and preference for higher releases (e.g. 14
&15)
21. The gateways shall have Operating Temperatures from at least -30 deg
C to 70 deg C.
22. All mounting accessories should be provided.
23. The gateways shall be provided with full hardware capability, without
any software/licensing limitation.
24. The bidder shall provide all the support needed to establish the
integration to full satisfactory.
25. The Gateways shall have a self-diagnostic feature for:
4.25.1 RTC, Memory, Battery, Communication module & any others
26. The Gateways shall be able to configure the communication with
underlying nodes/Meters
27. The Gateways shall be able to pull data from the field devices and push
the data at configured intervals to the HES
28. Data acquisition (push/pull) frequency is programmable
29. Capable to priorities the control commands
30. Internal memory for storing internal data for at least 30 days
31. Support on demand read and ping of individual/group of meters
32. Support IPv4 and IPv6 network addressing
33. Communication
4.33.1 Support remote firmware upgrades & remote configurations
4.33.2 Configuration of programmable parameters of Smart meters
through HES
4.33.3 Keep the following records of events and Pass to HES
4.33.3.1 No of packet failure
4.33.3.2 Retry attempts
4.33.3.3 Missed periodic readings
4.33.3.4 Failure to connect
4.33.3.5 Tamper events
34. Enclosure for the Gateways:
 4.34.1 The gateways should be enclosed in appropriate housing for the
nature of installation.
4.34.2 The bidder shall ensure that the enclosure is at least IP67
rated, in case of direct outdoor installation. On the other hand,
for indoor applications (such as within buildings), a lower IP
rating can be considered.
35. Battery:
4.35.1 The bidder shall propose both options – AC powered as well as
battery powered gateways. Battery powered gateways may be
required in the case of water meters where no external source
of power is available, e.g. bulk meters, etc.
4.35.2 The Gateways to have a battery back-up for 1 hour for all
gateways (Optional item)
4.35.3 The battery life shall be at least 10 years.

SECURITY REQUIREMENTS
36. The bidder shall ensure that proposed solution shall comply with the
latest applicable IT and Telecom standards (such as UAE NESA (SIA) IA
V2, UAE DESC (ISR), UAE TRA, 3GPP, ETSI, ENISA, CSA, NIST, PCI,
ISO, GDPR etc.) along with client standards and requirements, included
in this TENDER or finalized during final solution design, where
necessary and required.
37. Bidder to ensure our information in the service (as per scope) shall be
governed/secured as per client information classification/protection
policy and Non-disclosure agreements (NDA).
38. The bidder shall list all the built-in security controls in the proposed
solution for the following domains including but not limited to:
4.38.1 Data Governance and protection
4.38.2 Data Security
4.38.3 Identity and Authentication
4.38.4 Network and Infrastructure Security
4.38.5 Cloud Security
4.38.6 Virtualization and Container Security
4.38.7 Application Security
4.38.8 Host Security
4.38.9 Security Monitoring
4.38.10 Security Assurance
39. Bidder shall submit risk assessment report identifying all the cyber
security risk towards the service (as per TENDER scope) and highlight
all built-in security controls to secure from those risks.
40. Bidder shall provide latest third party security assessment reports
(audit/penetration testing) on the proposed solution.
41. Bidder shall provide solution to ensure the privacy and integrity of
classified and personal information.
42. All fields that contain confidential information like Personally
Identifiable Information (PII), customer contacts, and call details must
be encrypted, tokenized and hashed depending on service requirements
(as per scope).
43. Project plan submitted by vendors should include timelines for fixing any
vulnerabilities.
44. Bidder shall include workshop/training to client security team on the
knowhow and implementation of built-in security controls of the
proposed solution.
45. Proposed solution shall support separation of data, signaling and
management traffic using secure network and application protocols.
46. Bidder to ensure proposed solutions will run the latest stable software,
operating system and firmware. Additionally, proposed solutions shall
be updated with the latest security software and firmware.
47. The Bidder shall ensure protection for the systems and all related data
against any potential cybersecurity threats including spyware, computer
viruses, phishing, DDoS, etc., during the entire implementation and
support period. The bidder shall provide the software/firmware update
during the lifetime of the system.
48. The bidder shall ensure that all software/firmware updates for any
identified software/firmware bugs or security threats related to the
systems provided, including the firmware/software/OS, are
immediately notified to client and shall submit detailed report including
mitigation plan.
49. The Bidder shall submit to client quarterly road map of updated
software releases/patches that are generally available against known
security vulnerabilities to the system along with the implementation
plan.
50. Bidder, during warranty period, will be deemed responsible to
communicate these formally (email, fax or letter) to the concerned
Etisalat team that operates the service which these systems are a part
of.
51. The proposed solution shall support role based access controls.
52. The proposed solution shall prevent data exfiltration (Data theft) through
following security controls but not limited to data leak prevention,
Access Control Lists, Encryption, Strong passwords etc.
53. The offered System shall have the capability of encrypting all classified
data and maintaining an acceptable performance. Standard algorithms
like AES shall be used with minimum encryption strength of 256 bit for
end-to-end transaction.
54. Secure protocols shall be configured to run on non-standard ports. Port
4222 shall be used for SSH.
55. If applicable, proposed solution shall support 802.1X Authentication.
56. The solution shall be designed with multi-tier architecture,
(Demilitarized Zone (DMZ), middleware, and private network). Any
system accessible from the Internet shall be on the DMZ and access to
internal sensitive data shall be secured through the middle tier
application proxy.
57. Software/Firmware
4.57.1 Ensure all system devices have update capability and can be
updated quickly when vulnerabilities are discovered
4.57.2 Ensure update files are encrypted and that the files are also
transmitted using encryption
4.57.3 Ensure that update files are signed and then validated by the
device before installing
4.57.4 Ensure update servers are secure
4.57.5 Ensure the product has the ability to implement scheduled
updates
58. Physical Security
4.58.1 Ensure the device is produced with a minimal number of
physical external ports (e.g. USB ports)
4.58.2 Ensure the firmware of Operating System cannot be accessed
via unintended methods such as through an unnecessary USB
port
4.58.3 Ensure the product is tamper resistant
4.58.4 Ensure the product has the ability to limit administrative
capabilities in some fashion, possibly by only connecting locally
for admin functions
4.58.5 Ensure the product has the ability to disable external ports
such as USB
5 ENDPOINT CHECKLIST REQUIREMENT
1. Use Tamper Resistant Product Casing:
5.1.1 Anomaly Detection from the endpoint to detect compromised
endpoints
5.1.2 Endpoints contain Sensors that trigger an alert when a
physically static device’s location is moved
5.1.3 Endpoints raise Alerts when either internal or removable
components are removed from the device
5.1.4 Device cannot be easily disassembled and that the data storage
medium is encrypted at rest and cannot be easily removed.
2. Secure remote management and endpoint administration. Logging and
Diagnostics for any remote activities.
3. Any interface used for administration or test purposes during
development should be removed from a production device, disabled or
made physically inaccessible.
4. Uniquely Provision and Personalize Each Endpoint Device Prior to
Fulfilment and use a private APN.
5. Use security gateways to protect legacy endpoints, communication and
connectivity.
6. Enforce mutual authentication with the platform and network peers to
prevent impersonation of the unauthenticated endpoint. Multi-factor
authentication is recommended where possible for critical endpoints.
7. Enforce Confidentiality and Integrity to/from the platform. Securing
data in endpoints involves data-at-rest (DAR) and data-in-use (DIU). The
protection strategy for data-in-motion (DIM) differs at the edge, the
cloud, and in the communications. Cryptography enforces data
confidentiality and ensures integrity of the data.
8. Support secure over the air application updates and patch management
for any new vulnerabilities. Security patches/updates should be applied
in a timely fashion without impacting the functionality of the device from
trusted patch servers.
9. Ensure that the device software/firmware, its configuration and its
applications have the ability to update Over-The-Air (OTA), that the
update server is secure, that the update file is transmitted via a secure
connection, that it does not contain sensitive data (e.g. hardcoded
credentials), that it is signed by an authorized trust entity and encrypted
using accepted encryption methods, and that the update package has
its digital signature, signing certificate and signing certificate chain,
verified by the device before the update process begins.
10. Enforce Memory Protection to protect from Clone Endpoint identities,
Impersonate IoT services, Deploy unauthorized patches or updates and
Make unauthorized changes to the Endpoint software.
11. Device Management and remote administration:
5.11.1 If a production device must have an administration port,
ensure it has effective access controls, e.g. strong credential
management, restricted ports, secure protocols etc.
5.11.2 Brute-force attack mitigation
5.11.3 Disabling the use of default or hardcoded passwords
5.11.4 Password best-practice enforcement
5.11.5 Disallowing display of user credentials on login interfaces
5.11.6 Enforcing thresholds and incremental delays for invalid
password attempts
12. Bidder to ensure their devices are patchable, rely on industry standard
protocols, do not use hard-coded passwords, and do not contain any
known security vulnerabilities
13. Do not place private cryptographic components in insecure storage on
Endpoints, such as SSH private keys, TLS private keys, or passwords
14. The product/service ensures that only authorized personnel have access
to personal data of users and data is anonymized whenever possible.
15. The endpoint should stores the minimum amount of personal
information from users if required and ensures that all personal user
data is encrypted at rest and in transit..
16. Do not embed remote administrative capabilities into a publicly
accessible application or API, use a separate and distinct
communications channel
17. Security monitoring and analysis. An Endpoint should log its own
behavior and intermittently upload this log to back-end services for
processing
18. Endpoints must always use standard cryptographic algorithms. These
algorithms should be implemented utilizing safe-coding practices, and
whenever possible, with libraries that are updated and maintained
regularly.
19. Consider restricting administrative access to a Virtual Private Network
(VPN)
20. Process for Device Decommissioning and Sunsetting. Ensure
decommissioned devices are backlisted by our service ecosystem and an
alarm is raised should such a device attempt to communicate with our
service platform.
21. Disclose the duration and end-of-life security and patch support (beyond
product warranty)
22. Control the installation of software in operating systems, to prevent
unauthenticated software and files from being loaded onto it.
23. Any applicable security features should be enabled by default, and any
unused or insecure functionalities should be disabled by default.
24. Establish hard to crack, device-individual default passwords and Ensure
default passwords and even default usernames are changed during the
initial setup, and that weak, null or blank passwords are not allowed.
25. Risk Segmentation - Splitting network elements into separate
components to help isolate security breaches and minimize overall risk.
Networks can be divided into isolated subnetworks to boost performance
and improve security.
26. Avoid provisioning the same secret key in an entire product family, since
compromising a single device would be enough to expose the rest of the
product family.