Solving IoT Issues: How to Choose Between Soracom Beam, Funnel, and Funk

Soracom Beam, Soracom Funnel, Soracom Funk

In this blog, we will discuss our IoT protocol conversion tool, Soracom Beam; our cloud integration service, Soracom Funnel; and our integration to Functions as a Service Provider tool, Soracom Funk. We will look at their core functions and help you decide which service works best from the perspective of several IoT project issues.

Soracom Beam, Funnel, Funk diagram

What are These Services, and How Do They Differ?

Soracom Beam, Funk, and Funnel are services that convert device-side communication protocols and add authentication information and proxy data. Proxy destination and authentication information can be set in the Soracom User Console, eliminating the need to make changes on the device side. This also allows for data to be sent to its destination without encryption or protocol management required on the device side.

SORACOM Beam / Funk / Funnel

  • Soracom Beam: Forwards data to any API endpoint (e.g., HTTPS, MQTTS, etc.)
  • Soracom Funk: Transfers data to Function as a Service provider (Example: AWS Lambda, Azure Functions, Google Cloud Functions, etc.)
  • Soracom Funnel: Transfers data to cloud services and platforms (e.g., Amazon Kinesis Data Streams, etc.)

What Path Does Data Take to These Endpoints, and Is It Secure?

The reason encryption is not required from the device is a function of cellular communication in general and Soracom’s system configuration; data being delivered to Soracom from the cellular provider is done without that data ever being accessible over the public internet.  For communications without application-layer encryption, the network route is directly from the device to Soracom’s IoT platform.

Soracom Diagram

Between Device and Cell Tower:

In this part of of the communication flow, cellular technologies, such as 3G and LTE, are natively encrypted. Since the communication layer is encrypted, the presence or absence of encryption at this stage is not necessary.

Between the Cell Tower and Cellular Carrier Facilities:

Unlike the internet, which can be used by anyone, the cellular carrier’s network provides secure communication. It is a closed network, meaning only facility managers with limited privileges can access it.

Between Cellular Carrier Facilities and the Soracom IoT Platform:

Our Cellular Partner’s facilities are connected to Soracom’s IoT platform via a dedicated leased line connection, which is also a secure closed network.

Between Soracom’s IoT Platform and the Cloud:

By introducing SoracomBeam, Funk, or Funnel in this phase, these services will perform encryption on the device’s behalf.

Use of Cloud Services and Issues With IoT Devices

It is common to apply encryption when transmitting data to cloud services via the Internet. Unfortunately, IoT devices are generally battery-powered devices that can only use low-layer communication protocols such as UDP and TCP, with upper layers such as HTTP potentially being self-implemented. This can lead to various challenges, such as battery consumption due to additional processor usage. Let’s address some of these problems:

Increased Battery Consumption and Data Traffic Due to Communication Protocol

IoT devices won’t always be deployed in an environment where a power supply is readily available, meaning many deployments will rely upon battery power. In these cases, even slight increases in power consumption caused by communication encryption and unnecessary data transmission will impact the device’s battery life.

To show how Soracom Beam can help solve this problem, let’s look at the example of Soracom customer Mixi. Mixi is developing a service called ” Mite Nemi Mimamori GPS,” which is intended to help parents locate their children. To this end, Soracom is helping the company develop a battery-powered device that transmits location information to the cloud. Given how essential battery life is to the user experience for such Business-to-Consumer products, the question on everyone’s lips becomes “how can the existing battery life be maximized?”

In this example, the data destination is the AWS cloud, where there is a data ingestion point for HTTPS. The device, however, sends data with UDP. At this stage, Soracom Beam converts the incoming UDP traffic to HTTPS, before forwarding it to AWS. As UDP uses roughly 20x less data than HTTPS, this not only saves cost but uses less CPU processing power in the process.

Difficult to Change Device Settings

There are also cases where updating the IoT firmware can become an issue. For example, when dealing with already deployed devices, making changes to authentication information or the destination of the data can be time-consuming and expensive. In most cases, the data destination is set in the firmware, and the device will have a mechanism for changing it. Alternatively, it may be able to be controlled by a smartphone with a settings application. Both of these examples, however, require time and effort to make individual changes to each device.

As a specific case, let’s take a look at Ratock’s ” LTE-M CO2 sensor RS-LTECO2 starter kit.” The RS-LTECO2  comes pre-installed with firmware that transmits data to the Soracom Unified Endpoint via UDP. 

Soracom Unified Endpoint is a service that provides an entry point for transferring data sent from devices to other Soracom services like Beam or Funnel. This allows a user to specify the Unified Endpoint as the data destination for all devices, and then make changes to the Beam configuration to address that data to its final destination (either on a device-by-device or group basis), avoiding the need to make changes to individual devices. These services can also be enabled and disabled easily via the Soracom User Console to allow for greater flexibility.

Which Service Should I Choose?

Finally, let’s look at how to choose between the three services. Essentially, the destination service and communication protocol will be selected in terms of which service is compatible. However, there are cases where both Soracom Beam and Funnel are compatible depending on the service to which it is linked, such as AWS IoT Core. Which service should you choose in this situation?

1. How to Choose Between Soracom Beam and Funnel: “Synchronous/Asynchronous Response After Sending Data”

There are cloud destinations, such as AWS IoT Core, that can be reached with both Soracom Beam and Funnel.

In such cases, it should be confirmed whether or not a response is needed from the destination cloud service when the device sends data to the synchronous process. Alternatively, if the transmission is completed when the data reaches Soracom and a response from the cloud service is unnecessary, asynchronous processing is acceptable.

When using Soracom Beam, the transfer destination response is returned to the device by synchronous processing. Soracom Funnel, on the other hand, processes requests asynchronously, and the response from the transfer destination cloud service is not returned to the device side.

Therefore, in cases where data can be sent asynchronously, and the destination is in the list of services supported by Funnel, it would be better to send it via Funnel. Conversely, Soracom Beam is ideal when synchronous processing is required, such as a device sending data and receiving a response from the destination service.

2. Linking to Function as a Service by Soracom Beam and Funk

If the linked service is a Function as a Service (hereafter referred to as FaaS) provider, data can be sent using either Soracom Beam or Funk.

With the update of Soracom Beam in December 2022, it became possible to add authentication information such as AWS Signature V4. Before this, Soracom Funk was introduced for linking to FaaS, but with this change, Beam supports AWS Lambda and Azure Functions.

When calling FaaS with SORACOM Beam, you can link to multiple FaaS providers or endpoints for each access path from the device. Therefore, if there are multiple destination functions in AWS Lambda or Azure Functions, and it is possible to send data from the device via HTTP, Soracom Beam is a valuable option. For more information, you can see the Beam Developer Documentation.

Soracom Funk, on the other hand, supports all FaaS of AWS Lambda, Microsoft Azure Functions, and Google Cloud Functions, and can send data with communication protocols other than HTTP, such as TCP and UDP. This makes Soracom Funk a natural fit for deployments that use a low-layer communication protocol, depending on the device.

3. SORACOM Beam for MQTT Communication

Customers who expect MQTT communication should use SORACOM Beam. When used, it is best to utilize ” Beam’s multi credentials per group function.” Although there is a mechanism to separate authentication information for each SIM, it is a best practice to assign a device certificate (X.509 certificate) to each device (SIM) in MQTT communication.


Got a question for Soracom? Whether you’re an existing customer, interested in learning more about our product and services, or want to learn about our Partner program – we’d love to hear from you!