Key Requirements for being a Messaging Supplier to Melrose Labs
Working with many partners in a large and diverse communications ecosystem brings strength to our services and value to our customers.
Mobile Network Operators
We will be using Melrose Labs Message Exchange for procurement of messaging suppliers and will commence procurement in December 2020. If you believe you can be a great supplier of SMS messaging to the CPaaS provider aiming to be Europe's no. 1, then sign-up now for partner announcements.
Our SMS messaging requirements span the following regions:
The requirements stated on this page will, where appropriate, be included in any subsequent agreements and will also include data protection, privacy and IT security agreements.
If you do not meet these requirements, we may be willing to provide SMS messaging infrastructure to your organisation free-of-charge or at discounted rates to enable you to meet these requirements.
Interconnect between Melrose Labs network and supplier network
- Protocol: SMPP v3.4 or v5
- Encryption: SMPP over TLS v1.1 or higher, or via VPN
- Redundancy: SMPP connection to two geographically separate locations
- Availability: 99.95%
- Minimum message throughput: 100 SMS/sec (subject to supplier coverage and traffic level)
SMPP Protocol Conformance
- Protocol Conformance Implementation Statement (PICS) should be provided by the supplier. This document indicates the level of SMPP support of supplier platforms. Testing of SMPP protocol support will be done for new suppliers to confirm SMPP support.
- SMPP TLVs supported.
- Delivery receipt format, support for
network_error_code TLVs, and delivery receipt error code list.
Message capabilities consistently supported by own platform and routes
- Character sets supported (data_coding / DCS) and character set indicated when default character specified (i.e. DCS=0)
- Protocol ID support
- UDHI support
- Source address support
- Storage of message content beyond 90 days (unless required by local regulations).
- Modification of content that will result in delivery of different message content (except where required by local regulations).
We aim to have connections with Messaging Aggregators in all countries throughout the world, in addition to the connections we have with Mobile Network Operators.
- Direct routes: Our preference is for direct routes from Messaging Aggregators to MNOs.
- Indirect routes: Routing from a supplier to another Messaging Aggregator is not prohibited. A direct route to an MNO must not be changed to an indirect route.
- Dynamic routing: When using dynamic routing to route messages upstream, Messaging Aggregators must ensure their routing does not result in any prohibited item mentioned in this document. If a supplier states that a route is direct to a certain MNO, then that routing must not be changed to indirect.
- Directness: Suppliers must identify for each destination network if the route from them is a direct route to an MNO SMSC or an indirect route.
- Route capability: Messaging capabilities supported by the route should be provided (i.e. traffic level/TPS, DCS, protocol ID, UDHI, source addressing, etc).
Any filtering implemented on the Messaging Aggregator's network should be notified to Melrose Labs.
- Fake delivery receipts - all delivery receipts indicating a successful delivery must be as a result of successful delivery to the mobile device.
- Routing messages outside of Europe when messages originate within Europe and are being delivered to a European destination.
- Routing of messages over a link that is not encrypted.
- Routing messages such that they will go over a link that is not encrypted on their path to an MNO SMSC.
- Delivery to mobiles via GSM/SIM gateway.
- Grey routing.
Mobile Network Operators
Messaging Aggregator points apply where MNO has outsourced direct delivery to third-party or is using a messaging platform without integrated SS7/SIGTRAN for GSM MAP.