Share your experience using Ericsson IoT Accelerator

My main use case for 1NCE is that the app I have consumes data from the connected devices and shows health, connectivity, and the basics metrics. It is currently in the development phase and in an internal environment. It's not a consumer-facing app.

From the development perspective, 1NCE helps me reduce time during development because I didn't have to build additional handling for different carriers or regions. It helped me with predictable connectivity, making testing smoother and allowed me to connect IoT devices. The single SIM and the flat pricing model made it easy to prototype and test without worrying about usage spikes and unexpected costs.

The best features 1NCE offers are that it's very easy to set up, has flat pricing, and offers long-term validity. I would recommend it for startups building IoT MVPs, enterprises with large device fleets, and developers who want plug-and-play connectivity. 1NCE provides secure and reliable SIM-based connectivity that works for smart meters and asset tracking, making it a great choice for IoT.

Out of those features, I find myself relying on and appreciating the global IoT connectivity most on a day-to-day basis. It works in 170 plus countries with single SIMs that work internationally without needing roaming configuration. The model is excellent with a pay-once, use-for-years approach that typically includes 10 years validity.

1NCE has positively impacted the project I'm working on by saving time during development because I didn't need to build additional handling for different carriers or regions. It gave me predictable connectivity, making things smoother. Along with the saved time, I can focus on more features.

The main problem 1NCE solved for me was removing the complexity around IoT connectivity and pricing. I could treat connectivity as a solved problem and focus on app features.

If I have to say how 1NCE can be improved, it's not suitable for high-bandwidth use cases. It's not suitable for heavy apps and video streaming. It's more focused on IoT than general cloud compute.

1NCE is very good and I have been using it, and I will recommend others as well. However, as I mentioned, it's not useful for video streaming apps or heavy apps, so they may need to increase their latency and flexibility.

I have been using 1NCE for the past 2.5 months in my app, and it helps me with the IoT section part.

Not specific to features, but for the IoT part, I feel it's very helpful in the logistics and smart cities industries. I feel it's not meant for video streaming or heavy apps.

If your product is very credible and developer-focused, you should get aligned with 1NCE. It's typically evaluated.

I would rate this product an 8 out of 10.

AWS IoT Core is used to stream in telemetric data from the vehicle. Predictive maintenance of vehicles is performed using this data to determine whether tires, the engine will fail, or if the vehicle needs scheduled maintenance, or if the vehicle is not fit to drive on the road because of detected defects or anomalies.

The telemetric data from the business side is used to do predictive maintenance.

A lot of AWS products are being used, almost a full stack with IoT ingestion, API Gateway, databases, MongoDB databases, lambdas, and containers. AWS IoT Gateway is used, and an in-house type of Greengrass product has been built. The core is only used because an IoT MQTT gateway is needed, and there are two choices: either AWS IoT Core can be used with less setup, or your own MQTT service can be set up, which has been considered but is not done today.

Kafka is used for message brokering. Kafka passes all the telemetric high-speed data and high-speed events. The only reason AWS IoT Core is used is mainly to avoid the setup, maintenance, and management of the MQTT service. The advantage is that it is a managed component from AWS which saves the hassle of setting it up yourself. It scales up fast, so there are no complaints there.

TLS encryption is used on the MQTT protocol, but no other specific security features are used. A custom certificate handling system has been built for short-lived and device-specific IoT device certificates, so a custom security model has been built.

AWS IoT Core is used for the core only, and events are streamed to Kafka where they are further processed. Whether AWS IoT Core or another solution is used, it would not make that big of a difference because it just throws the events to the Kafka broker. There are no lacking features because the pure core is used and the rest is managed in-house.

Discussions have been had with the AWS team itself. If AWS IoT Core is used just for basic functionality, it is very expensive. Price calculations were done together with AWS, the core product team, and the product manager for AWS IoT Core. They made an adaptation, and a few quarters ago, they introduced a feature that allows paying a decent price for just using the basic things that are needed. The price setting point of view is satisfactory.

Building it ourselves was looked at because it was too expensive. Some open source tooling was considered because the key thing about having a good solution is that the open source tools that could be found were more than enough. The key thing is, of course, to make it resilient.

Seven years.

The setup was quite straightforward. The team did the first prototyping and first testing in two or three days with an IoT device, so the implementation went pretty smoothly with no complaints.

Scalability is very important because millions of IoT devices are processed. Spike loads occur, and basic components are delivered by AWS. A custom layer has been written on top of what AWS provides. In general, everything that is needed is scalable.

A very good and close relationship has always been maintained with the AWS team, and it continues to be strong. If there is some issue or if advice is needed on how to use the product, even if the standard recommendation does not work for the specific needs, they help to find other ways. For instance, regarding network outages protection that was wanted, AWS suggested using an AWS product, but it was very expensive and had too much functionality. They helped to find other ways around this. The AWS team, technical experts, and technical support are very helpful, and satisfaction is high.

Positive

A commercial product is not really needed for this purpose. It can be done much better in-house.

The setup was quite straightforward.

Even with the discounts that were given with the reduced product, doing it yourself could be cheaper. Building it in-house could be done more cost-effectively, but the decision was made not to invest resources on this now. Once the business grows further, managing it in-house could become an option.

Even with the discounts that were given with the reduced product, doing it yourself could be cheaper.

If it is done in-house with the competences available and the foundations that are in place, it is normal that it can be done slightly cheaper.

The core only is used, and the reason is because it is the core business, and there are a lot of things that are done in-house and done more efficiently. For people who want to use basic functionality only, it is the easiest way to get started. If you do not have your own EKS scalability and self-healing layer on top of the EKS platform, AWS IoT Core is a must-have. Building up a self-healing, scalable, and autoscalable EKS platform on top of what AWS has will take a very long time. If you are a smaller organization that does not have this capability, it would be a waste of effort to not use the AWS managed service.

For the part that is used, a rating of nine out of ten is given because AWS IoT Core does what it needs to do, it is quick to set up, and there have been no issues with it to date.