> 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/what-is-mioty.md). # O que é MIOTY? MIOTY explicado — o protocolo LPWAN ETSI TS 103 357 que usa divisão de telegramas para IoT resistente a interferências. **MIOTY** é um protocolo de rede de área ampla de baixa potência (LPWAN) concebido para ambientes industriais onde as condições de rádio são hostis e o número de dispositivos é elevado. Foi desenvolvido no **Instituto Fraunhofer de Circuitos Integrados (IIS)** e normalizado pela ETSI como **TS 103 357**, onde é especificado como **TS-UNB** — Telegram Splitting Ultra Narrow Band. Esse nome não é mero enfeite: a divisão de telegramas é a técnica que define o protocolo e explica quase tudo o que o MIOTY faz bem. O MIOTY é a mais recente das duas tecnologias LPWAN suportadas pela Kilo e está a ganhar terreno rapidamente — não pela novidade, mas porque resolve um problema que a primeira geração de LPWAN deixou em aberto. Essas tecnologias anteriores tinham de trocar alcance por capacidade e robustez. O MIOTY foi concebido depois de esse compromisso já estar bem compreendido, e foi projetado desde a camada física para o evitar. Tal como outras tecnologias LPWAN, o MIOTY transporta pequenas mensagens de sensores alimentados por bateria a longas distâncias, com um custo energético muito baixo. O que o distingue é a forma como sobrevive às interferências. Em vez de tentar enviar uma mensagem inteira através de um canal ruidoso numa única tentativa, o MIOTY parte do princípio de que o canal é ruidoso e projeta-se desde o início em torno dessa suposição. *** ### Divisão de Telegramas — a Ideia Central #### A mensagem é protegida e depois dividida em rajadas de rádio Quando um endpoint tem dados para enviar, o MIOTY não transmite esses dados como um único pacote. A mensagem — o *telegrama* — é primeiro codificada com correção de erros antecipada e intercalada, e depois dividida em pequenos subpacotes. Um telegrama curto torna-se **24 rajadas de rádio**, cada uma com duração de apenas cerca de **15 milissegundos**; cargas úteis mais longas acrescentam novas rajadas. Cada rajada transporta um fragmento mais a informação necessária para o voltar a colocar na sequência correta. A redundância é mais importante do que a divisão. O código de correção de erros é aplicado *antes* da divisão e distribuído por cada rajada, por isso nenhuma rajada é crítica — perder uma custa-lhe uma parte da redundância, não um pedaço da mensagem. #### As rajadas são distribuídas por frequência e por tempo Esses subpacotes são então transmitidos por **frequências diferentes e em momentos diferentes**. Nenhum fragmento fica no mesmo canal no mesmo instante, e a transmissão completa é deliberadamente distribuída por vários segundos e duas dezenas de portadoras, em vez de concentrada. Um único interferente — um motor, um equipamento de soldadura, um rádio concorrente, uma rajada de ruído de banda larga — só consegue ocupar uma pequena fatia dessa distribuição. #### O recetor reconstrói a mensagem a partir do que sobrevive A estação base recolhe as rajadas que ouviu e reconstitui o telegrama. O ponto crucial é que não precisa de todas. Como a correção de erros está distribuída por toda a transmissão, o recetor **reconstrói a mensagem completa mesmo quando até 50% das rajadas de rádio são perdidas** devido a interferência ou colisão. Leia isso com precisão, porque é fácil exagerar: significa que metade das *rajadas dentro de uma mensagem* pode ser destruída e, ainda assim, a mensagem chega intacta. Um interferente tem de eliminar mais de metade de uma única transmissão, tanto no tempo como na frequência, para lhe custar uma leitura. O que seria uma entrega falhada num protocolo de pacote único é, para o MIOTY, uma entrega bem-sucedida normal. #### Porque é que isto muda o resultado A interferência deixa de ser um evento binário. Numa transmissão convencional de pacote único, uma colisão destrói a mensagem e o endpoint tem de repetir — gastando bateria e acrescentando à congestão que causou o problema. Com a divisão de telegramas, uma colisão destrói um fragmento. O resto do telegrama continua a chegar, a mensagem continua a ser descodificada e não é necessária nenhuma repetição. É por isso que o MIOTY se mantém fiável em pisos fabris, no interior de edifícios densos em metal e em ativos que se deslocam através de condições de RF variáveis. *** ### Como é construída uma Rede MIOTY A arquitetura do MIOTY merece ser compreendida nos seus próprios termos, porque não corresponde de forma direta a outras topologias LPWAN. #### Endpoints Os endpoints são os sensores e localizadores no terreno. Cada um é identificado por um **EUI**, e o seu tráfego é protegido com uma **chave de sessão de rede** estabelecida quando o endpoint é ligado à rede. Os endpoints são alimentados por bateria e concebidos para longos períodos de serviço — despertam, transmitem um telegrama curto em rajadas dispersas e voltam a dormir. Como a entrega bem-sucedida não depende de repetições, o custo energético de uma mensagem mantém-se previsível mesmo em ambientes congestionados. #### Estações base Os endpoints transmitem para **estações base**. Uma estação base escuta todo o espectro, capta os subpacotes de todos os endpoints dentro do alcance e executa a reconstituição e a correção de erros que transformam esses fragmentos de volta em telegramas. Uma única estação base foi concebida para servir **milhares de endpoints** — a tolerância a colisões do protocolo é precisamente o que torna essa densidade viável em vez de meramente teórica. Aqui não existe uma gateway de encaminhamento de pacotes no sentido do LoRaWAN. A estação base não é um relé transparente que empurra quadros de rádio brutos para a upstream; é o ponto onde o telegrama se torna uma mensagem. #### O centro de serviço As estações base ligam-se a um **centro de serviço** usando **BSSCI** (Base Station Service Center Interface), a interface normalizada entre os dois. Essa ligação é protegida por certificado com TLS mútuo, pelo que cada lado autentica o outro e a ligação entre o terreno e a rede é encriptada de ponta a ponta. O centro de serviço é onde os endpoints são provisionados, onde as estações base são associadas e onde as ligações ascendentes são encaminhadas para as aplicações. *** ### Alcance, Escala e Energia Os valores abaixo vêm do Fraunhofer IIS e da MIOTY Alliance. Cada um depende das respetivas condições, por isso são apresentados com elas — um número sem as suas suposições não serve de muito quando se está a planear uma instalação. | | Valor | Condições | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | **Alcance** | Até **15 km** em terreno plano e rural; cerca de **5 km** em centros urbanos | bandas Sub-GHz sem licença | | **Endpoints por estação base** | Até **110,000** | A cerca de 2,5 km de alcance — não no valor de 15 km acima | | **Mensagens por estação base** | Até **3,5 milhões por dia** | Modo de consumo ultra baixo, cargas úteis pequenas, endpoints a reportar cerca de uma vez por hora | | **Duração da bateria** | Cerca de **10 anos** com uma única pilha AA de 2.200 mAh, com uma mensagem a cada 15 minutos; **20 anos e mais** a taxas de reporte mais baixas | Depende do tamanho da carga útil, do intervalo e da química da célula | | **Velocidade** | Até **120 km/h** com desempenho total | Endpoints em ativos móveis | | **Taxa de dados** | Cerca de **500 bit/s** | Sub-GHz; espaçamento entre portadoras de \~2,4 kHz | Essas propriedades reforçam-se mutuamente. A robustez reduz as repetições; menos repetições preservam tanto a duração da bateria como o tempo de ocupação do ar; o tempo de ocupação preservado é o que permite que uma única estação base suporte tantos endpoints. O valor da densidade é um dividendo da tolerância à interferência, não uma afirmação independente. O valor da mobilidade merece uma nota, porque é aquele que as pessoas tendem a assumir ser marketing. Não é um truque de forma de onda — espalhar um telegrama ao longo de segundos e de portadoras significa que um endpoint em movimento amostra muitos momentos e muitos canais em vez de apostar a mensagem num só, e é o processamento de sinal da estação base que eleva a velocidade viável até 120 km/h. O Fraunhofer mediu a penalização de um canal com desvanecimento face a um canal estático em menos de 2 dB. *** ### MIOTY no Kilo IoT A Kilo suporta MIOTY juntamente com LoRaWAN, pelo que o protocolo é uma escolha de design e não um compromisso de plataforma. Quando os seus endpoints começam a reportar, comportam-se como qualquer outro dispositivo na plataforma: dados normalizados, painéis, regras e alarmes funcionam todos da mesma forma, independentemente do rádio que entregou a leitura. * Para trazer dados MIOTY para a sua organização Kilo, adicione o [conector MIOTY](/kilo-docs-pt/kilo-iot-server/connectors/mioty-connector.md). * Para registar e gerir as estações base que servem os seus endpoints, consulte [estações base MIOTY](/kilo-docs-pt/kilo-iot-server/gateways/mioty-base-stations.md). * Para operar a sua própria infraestrutura de centro de serviço, consulte o [Centro de Serviço Kilo MIOTY](/kilo-docs-pt/kilo-center/kilo-mioty-service-center.md). Continue com [Principais Benefícios do MIOTY](/kilo-docs-pt/kilo-iot-server/connectors/mioty-connector/core-benefits-of-mioty.md) para ver o que a divisão de telegramas oferece na prática. *** MIOTY é uma marca registada da MIOTY Alliance. Para a especificação e o ecossistema mais amplo, consulte [mioty-alliance.com](https://mioty-alliance.com). --- # 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/what-is-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.