In der 3GPP-Standardisierung hat man frühzeitig den Bedarf an optimierten Lösungen für den IoT-Markt erkannt und spezifische Verbesserungen für die sogenannte Machine-Type-Communication (MTC) entwickelt. So spezifizierte das Gremium in Rel. 10/11 Leistungsmerkmale, die ins-besondere das mobile Kontrollnetz vor Überlastung durch die vielen IoT-Devices schützen sollen. Die Netzbetreiber möchten gewappnet sein, wenn möglicherweise einige tausend Geräte gleichzeitig versuchen, Verbindung zum Netz aufzunehmen. Das kann beispielweise beim Wiederhochfahren des Stromnetzes nach einem Stromausfall sein, also einem plötzlichen Ereignis. Dazu wurden Überlastmechanismen und Möglichkeiten zur Reduzierung des Signalisierungsverkehrs eingeführt.
Viele IoT-Anwendungen wie Sensornetzwerke versenden nur selten Daten und müssen nicht sekundengenau arbeiten. Diese Geräte haben die Möglichkeit, dem Netz mitzuteilen, dass sie bereit sind, längere Wartezeiten beim Verbindungsaufbau hinzunehmen – sogenannter „delay tolerant access“. Mit Rel. 10 steht ein Verfahren zur Verfügung, das es dem Netz im Falle einer Überlastung erlaubt, Ver-bindungsanfragen dieser Geräte zunächst abzuweisen und sie auf später zu vertrös-ten – sogenannte „extended wait time“. Bei dem nachfolgenden Rel. 11 kann der Zugang zum mobilen Netzwerk über Zugangsklassen gesteuert werden. Ein Gerät kann eine Verbindung nur dann aufbauen, wenn es die Klasse besitzt, die das Netz gerade erlaubt. Dazu versendet das Netz eine Bitmap (eaB-Barring-Bitmap), die kennzeichnet, welchen Klassen der Zugang erlaubt ist.
In Summe wurde mit den in Rel. 10 und 11 eingeführten Verfahren sichergestellt, dass die mobilen Netze heutige und zukünftige IoT-Anwendungen und -Geräte sicher und stabil bedienen können, ohne den mobilen Breitbandservice zu gefährden. Nun fehlten noch optimale Lösungen für IoT-Geräte mit wenig Datenverkehr, geringem Stromverbrauch und niedrigen Kosten. Damit hat das Gremium in Rel. 12 begonnen. Aber schnell war klar, dass es keine einfache gemeinsame Lösung für alle Anwendungen geben wird. Dazu sind die Anforderungen von Applikationen wie Containertracking, Mülltonnenmanagement, Smart-Meter, Agrarsensoren oder Sport- und Gesundheits-Trackern zu unterschiedlich. Rel. 12 konzentriert sich deshalb zunächst auf die Bereiche Stromverbrauch und kostengünstige Modems. Daraus resultiert ein Stromsparmodus (Power-Sa-ving-Mode – PSM), der insbesondere für batteriebetriebene Geräte wichtig ist, und eine neue LTE-Gerätekategorie 0, die nur 50 Prozent der Komplexität eines Kategorie-1-Modems aufweisen soll.
Stromsparmodus für mobile Anwendungen
Der PSM-Prozess startet nach dem Beenden einer Datenverbindung beziehungsweise nach der periodischen TAU-Prozedur (Tracking-Area-Update). Zunächst geht das Gerät in den normalen Idle-Mode, in dem es in zyklischen Abständen in den Empfangsmode schaltet, um Nachrichten zu empfangen. So ist es weiterhin durch Paging erreichbar. Nach Ablauf des Timers T3324 startet der PSM-Mode und schaltet das Modem in den Stromsparmodus. In diesem Mode ist das Gerät jederzeit in der Lage, Nachrichten zu senden, da es im Netzwerk registriert bleibt. Weil aber der Empfangsteil abgeschaltet ist, ist es durch Paging nicht erreichbar.
PSM ist also insbesondere für Sensornetzwerke geeignet, die nur selten und wenige Daten zum Gerät transportieren müssen. Für Anwendungen, die eine schnelle Antwort des Sensors erfordern oder eine zeitkritische Reaktion erwarten, ist dieses Verfahren nicht geeignet. Applikationen die den Stromsparmodus anwenden wollen, müssen dieses Verhalten tolerieren und schon im Design die optimalen Timerwerte für Idle- und PSM-Mode festlegen. End-to-end-Tests sind in diesem Fall unerlässlich, um Applikationsverhalten und Netzwerkverhalten aufeinander abzustimmen.