Traffic Delivery To/From Customer Applications

After defining a Messaging Endpoint Profile, the profile can be associated to one or more Service Templates. When a Messaging Endpoint Profile is associated to a Service Template, uplink data received from the devices associated to that Service Template will be routed to the upstream applications specified Messaging Endpoint Profile. The customer application defined in the Messaging Endpoint Profile may also initiate downlink data to the Service Template devices using the credentials defined in the said Messaging Endpoint Profile.

Primary and Secondary Messaging Endpoint Profiles can be associated to a Service Template. The primary profile is used by default. If not available the secondary profile will be used.

 

Traffic Segregation And Delivery

Upstream traffic splitting/segregation can be achieved in several ways. The simplest traffic segregation method is by grouping devices whose data need to be forwarded to specific target application into Service Templates and then associating specific Messaging Endpoint Profiles to each Service Templates. The configured Primary and Secondary Messaging Endpoint profiles are then used to deliver uplink data from all devices associated to the Service Template.

The IoTGtw cloud service also supports a more sophisticated traffic segregation for devices that have multiple traffic strands that need to be delivered to different sets of customer upstream applications. Traffic strands can be distinguished by the Service Access Point for both uplink and downlink.

Note: Traffic strand is for example: 10 devices are associated to a Service Template. The Service Template is configured to allow 5 different Service Access Points to be used by the devices. The device traffic sent/received through each Service Access Point is considered a distinct traffic strand. The Service Template can be configured such that each traffic strand is delivered to the customer upstream application using distinct Messaging Endpoint Profile set (primary and back).

For example traffic strand 1 from the devices in Service Template X need to be delivered to customer upstream application in AWS using MQTT, traffic strand 2 needs to be delivered to the customer application at the customer data centre using UDP sockets and all other traffic need to be delivered to the customer application instances hosted in Azure using RESTful APIs.

 

The above setup can be achieved by:

1. Firstly ensure the upstream_traffic_segregation_service is active on your account subscription or is subscribed to as an add-on
2. Create the necessary Messaging Endpoint Profiles with the appropriate target applications endpoint details, credentials, protocol, etc.
3. In the device Service Template select a Primary and Secondary Catch-all Messaging Endpoint Profiles. This set of profiles will be used as catch-all for all upstream traffic except for the upstream traffic strands configured to be segregated.
4. In the Service Template, under Upstream Application Messaging Endpoint Profile, Add a Segregated Strand, select the service access point and select the primary and secondary Messaging Endpoint Profile to use for this particular traffic strand.
5. Repeat step for to add more traffic strands to be segregated and routed to specific Messaging Endpoint Profile (target application).

 

Traffic Filtering

It is possible to filter out and deliver only a specific strand to the defined customer upstream application. In this case only the matching traffic strand are transmitted to the customer upstream application. All none matching traffic strand are not transmitted upstream but could be stored instead if the Service Template meta-data and payload storage policy are configured as such.

 

Note: The Messaging Endpoint Profile connection details (IP address/host, credentials, IP-whitelisting, etc) are also used to validate the customer application when performing downlink messaging operations such as submit message, retrieve messages, etc using the messaging API service.