> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-pt/kilo-iot-server/connectors/mioty-connector/why-choose-mioty.md). # Porquê Escolher MIOTY? MIOTY vs LoRaWAN — como a divisão de telegramas, as estações base e o BSSCI determinam qual o protocolo LPWAN adequado ao seu local. Escolher um protocolo LPWAN é uma questão sobre o seu ambiente, não sobre qual tecnologia é melhor em abstrato. MIOTY, LoRaWAN e LR-FHSS fornecem todas mensagens pequenas de dispositivos alimentados por bateria a longas distâncias. Diferem naquilo que assumem sobre o mundo através do qual essas mensagens viajam — e é essa suposição que deve decidir a sua escolha. O MIOTY pressupõe que o canal é hostil e que a população de dispositivos é grande, e desenha para ambos desde a camada física. *** ### O caso a favor do MIOTY #### A robustez já vem incorporada, não é acrescentada depois A maioria das estratégias de fiabilidade é reativa: detetar a falha, depois tentar novamente. O MIOTY é proativo. Ao dividir cada telegrama em subpacotes distribuídos por frequência e tempo, e ao reconstruir a mensagem a partir de um conjunto parcial deles, trata a perda como a condição esperada e não como a exceção. Não há uma tempestade de novas tentativas para gerir em condições congestionadas, porque a primeira tentativa normalmente tem sucesso mesmo quando parte dela não chega. #### Densidade sem degradação As redes tendem a degradar-se à medida que se enchem, porque mais dispositivos significa mais colisões e mais colisões significa mais tentativas — um ciclo de feedback que piora exatamente quando a implementação se torna valiosa. Quando as colisões custam fragmentos em vez de mensagens, esse ciclo não se fecha. É isto que lhe permite ter milhares de endpoints por estação base, e é isso que torna práticas as implementações ao nível de um local ou de um portefólio sobre uma infraestrutura modesta. #### Uma base aberta e padronizada O MIOTY é especificado pelo ETSI como **TS 103 357** — atualmente a parte 2, versão 2.1.1 (2024) — sob o nome TS-UNB. Está a comprar com base numa norma publicada, com um ecossistema multivendor por trás, e não na interpretação de um único fornecedor. Os fornecedores de endpoints e de estações base implementam a mesma especificação, e a [Aliança MIOTY](https://mioty-alliance.com) mantém o ecossistema em torno dela. A interface entre a estação base e o centro de serviços, **BSSCI** , é especificada separadamente pela Aliança. *** ### MIOTY e LoRaWAN, lado a lado O Kilo suporta ambos. A comparação abaixo é uma orientação técnica para escolher a ferramenta certa para um determinado local — não é um argumento contra nenhum dos protocolos. | | **MIOTY** | **LoRaWAN** | | ------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------- | | **Norma** | ETSI TS 103 357 (TS-UNB) | Especificação LoRaWAN (LoRa Alliance) | | **Técnica principal** | Divisão de telegramas — subpacotes por frequência e tempo | Modulação LoRa de espectro espalhado por chirp | | **Gestão de interferências** | Reconstrói o telegrama a partir de um conjunto parcial de rajadas | Entrega ao nível da mensagem; uma colisão custa a mensagem | | **Infraestrutura de campo** | As estações base recompõem os telegramas | Os gateways encaminham os pacotes para um servidor de rede | | **Interface de backhaul** | BSSCI sobre TLS mútuo protegido por certificado | Encaminhamento de pacotes para o servidor de rede | | **Ecossistema de dispositivos** | Base de fornecedores industriais em crescimento | Catálogo de sensores muito vasto, maduro e abrangente | | **Ponto ideal** | Implementações ruidosas, densas ou em movimento | IoT de uso geral e amplo, com grande escolha de hardware | #### Onde as arquiteturas realmente diferem A distinção estrutural vale a pena ser dita claramente, porque molda a forma como planeia um local. No LoRaWAN, os gateways encaminham os pacotes de rádio e o servidor de rede faz o trabalho do protocolo — o gateway é um retransmissor. No MIOTY, o **estação base** é onde os subpacotes são recolhidos e o telegrama é recomposto; está a fazer a reconstrução, não a passar quadros brutos adiante. As estações base ligam-se então a um **centro de serviço** sobre **BSSCI**, numa ligação TLS mútuo protegida por certificado. Não existe um gateway de encaminhamento de pacotes no sentido do LoRaWAN, por isso planeie a cobertura MIOTY em torno das estações base e do respetivo backhaul, e não em torno de uma frota de gateways. *** ### Como decidir Escolha **MIOTY** quando: * A interferência é uma limitação conhecida — pisos de fábrica, maquinaria pesada, estrutura metálica densa, espectro congestionado * Está a implementar milhares de endpoints e quer manter baixo o número de estações base * Os dispositivos estão em movimento, ou o ambiente à sua volta muda * Leituras perdidas têm um custo real — registos de conformidade, dados de faturação, tendências de falha Escolha **LoRaWAN** quando: * O ambiente de rádio é razoavelmente limpo e a contagem de dispositivos é moderada * O catálogo mais amplo possível de sensores prontos a usar é importante para a sua implementação * Quer o ecossistema LPWAN mais estabelecido para uma implementação de uso geral E não é uma escolha de um ou outro. Nada o impede de usar MIOTY onde o RF é difícil e LoRaWAN onde não o é — dentro da mesma organização Kilo, nos mesmos painéis, alimentando as mesmas regras. Quando os dados entram na plataforma, são normalizados, por isso o protocolo que transportou uma leitura deixa de importar no momento em que ela chega. *** ### Um servidor de rede, ou uma plataforma Há uma segunda decisão por trás da decisão sobre o protocolo, e vale a pena separá-la: um servidor de rede MIOTY e uma plataforma IoT não são o mesmo produto. Um centro de serviços move mensagens. Gere estações base e endpoints, trata uplinks e downlinks, e passa os dados adiante. Essa é uma camada necessária e exigente — mas, por si só, dá-lhe telemetria, não respostas. Tudo o que realmente quer *fazer* com uma leitura — representá-la, gerar alertas, agir sobre ela, guardá-la para uma auditoria — acontece noutro lugar. O Kilo dá-lhe ambos os caminhos: * **Kilo Center — a edição Community.** O nosso centro de serviços MIOTY de código aberto. Aloje-o você mesmo, seja dono da infraestrutura de ponta a ponta e integre-o com o que quer que execute a jusante. É um servidor de rede MIOTY: estações base, endpoints, tráfego e uma consola de operador. Veja [Centro de Serviço Kilo MIOTY](/kilo-docs-pt/kilo-center/kilo-mioty-service-center.md). * **Kilo Cloud — a edição Enterprise, integrada.** A edição Enterprise do centro de serviços é executada dentro do Kilo Cloud, por isso não há qualquer infraestrutura MIOTY para alojar. Registe um [conector MIOTY](/kilo-docs-pt/kilo-iot-server/connectors/mioty-connector.md) , aponte as suas estações base para ele, e os seus endpoints chegam a uma plataforma IoT completa em vez de a um simples servidor de rede. Esse segundo caminho é o que transforma o MIOTY de uma fonte de dados numa operação. As mesmas leituras entram no motor de regras, nos alertas com escalonamento, nos painéis, no Digital Building Twin, no controlo de acesso multi-inquilino e no registo de auditoria — a maquinaria que o resto da sua frota já utiliza. Um endpoint MIOTY e um sensor LoRaWAN tornam-se o mesmo tipo de objeto no momento em que os seus dados são normalizados, e uma única regra pode raciocinar sobre ambos. ### A iniciar uma implementação MIOTY no Kilo Os dados dos endpoints MIOTY chegam à sua organização através do [conector MIOTY](/kilo-docs-pt/kilo-iot-server/connectors/mioty-connector.md) , e as estações base que servem esses endpoints são registadas e geridas sob [estações base MIOTY](/kilo-docs-pt/kilo-iot-server/gateways/mioty-base-stations.md). *** MIOTY é uma marca registada da Aliança MIOTY. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kiloiot.io/kilo-docs-pt/kilo-iot-server/connectors/mioty-connector/why-choose-mioty.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.