This repository aims to promote the development of a multi-vendor management platform for CPEs and IoTs. Any device that follows the TR-369 protocol can be managed. The main objective is to facilitate and unify device management, which generates countless benefits for the end user and service providers, suppressing the demands that today's technologies require: device interconnection, data collection, speed, availability and more.
The advent of the Internet of Things brings countless opportunities and challenges for service providers, with over a billion devices across the globe today making use of TR-069, what is the future of the protocol and what can we expect ahead?
The CWMP (CPE Wan Management Protocol), better known as TR-069, opened many doors for the ecosystem of providers, through which it is possible to deliver services with agility, which meet or exceed customer expectations, with proactive management and secure network, also bearing in mind the lower cost and greater efficiency for service providers.
With the rise of what we now call the smart home, the Internet of Things and the demand for increasingly interconnected and cloud-based environments, new demands and obstacles have emerged, opening the door to the creation of a new form of communication that meets the needs of current market needs.
There is a fierce race to monetize the IoT devices that are now part of the connected home and other environments. As a result, many companies are creating their own proprietary solutions; this is understandable given such pressure generated by the promise of Smart Home monetization. Unfortunately, these applications contribute to a poor ecosystem, where a provider ends up dependent and limited to a vertical solution, from a single vendor. This generates an low competition environment (which leads to greater risks), less innovation, and the potential for very high cost solutions.
The technologies behind Wi-Fi, device-to-device connectivity, the Smart Home and IoTs are constantly evolving and improving. It is important that when service providers look for a solution, they look for something that is "future proof", always thinking ahead.
Seeking to solve the challenges mentioned above, providers and manufacturers together developed the USP (User Services Platform), defined by the Broadband Forum's TR-369 standard, which is the natural evolution of the TR-069. This new standard is designed to be flexible, secure, scalable and standardized to meet the demands of a connected world today, and in the future.
leandro@leandro-laptop:~$ cd oktopus/devops leandro@leandro-laptop:~/oktopus/devops$ docker compose up
leandro@leandro-laptop:~$ cd oktopus/backend/services/mochi/ && go run cmd/main.go -redis "127.0.0.1:6379"
leandro@leandro-laptop:~$ cd oktopus/backend/services/controller/ && go run cmd/oktopus/main.go -u root -P root -mongo "mongodb://127.0.0.1:27017"
leandro@leandro-laptop:~$ cd oktopus/backend/services/socketio && npm i && npm start
leandro@leandro-laptop:~$ cd oktopus/frontend && npm i && npm run dev
You might follow the instructions to build obuspa at their repo QUICK_START_GUIDE.md and remember to define 'INCLUDE_PROGRAMMATIC_FACTORY_RESET' at 'vendor_defs.h' inside src/vendor folder, also advice you to build it with make tool.
You can customize 'oktopus-mqtt-obuspa.txt' accordingly to your needs, there you can change broker address, client password, and etc. '-i' option defines the interface your usp packets will go through, in this case it's localhost, also keep in mind that after you run obuspa if you made a change to 'oktopus-mqtt-obuspa.txt' and want it to take effect you must delete '/usr/local/var/obuspa/usp.db' file before running the agent again (docs provide you other methods to do it too).'-r' option defines the config file you want the agent to use.
Run agent:
leandro@leandro-laptop:~/oktopus$ obuspa -p -v 4 -r agent/oktopus-mqtt-obuspa.txt -i lo
Obuspa has a lot of info and docs at their repo, which shows you many options to set your environment and customize agent to your embedded project. This basic agent has the purpose to test oktopus connection and shows an idea of how it's like with true devices, although with those, you're able to explore much more parameters and execute lots of configurations. Obuspa has default parameters and mocked info:
In case you want a more complete and real-world simulation of devices you might use Oktopus TR-369 Agent Simulator.
If you'd like to know how to donate above Github Sponsors values, start a partnership or somehow to contribute to the project, email leandro@oktopustr369.com, every contribution is welcome, and the resources will help the project to move on. Also, if your company uses this project and you'd like your logo to appear up here, contact us. --------------------------------------------------------------------------------------------------------------------------------------------------------
The project goals are organized with milestones that have a due date, just like a sprint. Those issues grouped in milestones are done and have their status updated in a kanban board.
Are you going to use our project in your company? would like to talk about TR-369 and IoT management, we're online on Slack.
If you are interested in internal information about the team and our intentions, visit our Wiki. [DEPRECATED]
--------------------------------------------------------------------------------------------------------------------------------------------------------Bibliographic sources: MU-461.pdf, TR-369.html, USP Training Session SlidesTR-369.html