BLE – Ein kurze Einstiegshilfe in die Welt von Bluetooth Low Energy

Björn Schmitz

11/30/2018

Als die ersten Bluetooth Low Energy Geräte in den Markt kamen, hatte BLE geradezu etwas Mystisches. Jeder wollte diese Technologie nutzen, auch wenn kaum jemand so richtig verstand wie es funktioniert. Hinzu kam, dass die Integration von BLE damals harte Arbeit war. Um mit BLE zu arbeiten, musste man sich in der Regel umfassend mit der Bluetooth Spezifikation und der genutzten Stack-Implementierung befassen. Das hat sich zum Glück geändert. Mit der weiten Verbreitung von BLE wurde auch die BLE-fähige Hardware immer besser bedienbar. Heute gibt es eine umfangreiche Liste an SoCs und Modulen, welche sich mit sehr geringem Aufwand programmieren lassen. Trotzdem sollte man ein gewisses Grundverständnis mitbringen, um die richtige Hardware und Software auswählen zu können. In diesem Beitrag versuche ich eine kurze Einstiegshilfe zu geben, für alle die sich zum ersten Mal mit dem Thema beschäftigen. Außerdem versuche ich gängige Missverständnisse zu klären und die Limitierungen der Technologie zu beleuchten.

Wer außerdem etwas tiefer in die Welt von BLE einsteigen möchte, dem empfehel ich auch meinen weiterführenden Artikel:

Niedrige Latenzen mit Bluetooth Low Energy

Hier geht es vorallem darum, wie man möglichst niedrige Latenzen mit BLE erreicht. Um dies zu erklären gehen ich allerdings auch auf einige Grundlagen ein, die für ein allgemeines Verständniss von BLE interessant sind.

Welche Hardware eignet sich für mein Projekt?

BLE-fähige Hardware gibt es inzwischen jede Menge auf dem Markt. Welche davon für das eigene Projekt geeignet ist, hängt von dem konkreten Anwendungsszenarien ab.

SoC oder integriertes Modul

Ob ein integriertes Modul oder ein reiner SoC zum Einsatz kommt, hängt vor allem von der Stückzahl ab. Bei hohen Stückzahlen machen sich die geringeren Kosten des SoC bemerkbar. Bei geringeren Stückzahlen zeichnen sich die integrierten Module durch geringere Entwicklungskosten aus. Zudem verfügen Module, sofern diese über eine integrierte Antenne verfügen, in der Regel über Vor-Zertifizierungen für bestimmte Regionen. Kommt ein SoC zum Einsatz muss für jedes Land eine entsprechende Zertifizierung durchgeführt werden. Ein Vorteil der SoCs ist allerdings die Möglichkeit das HF-Front End sowie die Platzierung der Antenne selbst gestalten zu können. Hierdurch können unter Umständen deutlich höhere Übertragungsreichweiten erreicht werden.

Länderzulassung bei BLE-Modulen

Entscheidet man sich für ein vollständig integriertes BLE-Modul mit integrierter Antenne, hat man oft den Vorteil, dass die Module für die entsprechenden Länder vorzertifiziert sind. Dieses Thema wird oft als weniger wichtig angesehen, kann aber entscheidend sein, wenn man vor hat, sein Produkt in vielen Regionen der Welt zu verkaufen. Will man sein Produkt überall auf der Welt anbieten, kann man durchaus mit sechsstelligen Kosten für die Zertifizierungen rechnen. Hier bieten Vorzertifizierungen in den entsprechenden Ländern enormes Einsparpotential.

Man sollte jedoch vorsichtig bei der Verwendung von Modulen ohne metallische Schirmung sein. Diese erhalten z.B. in USA und Kanada auf Grund der regulatorischen Vorgaben keine vollständige Zertifizierung. In Süd-Korea ist die Vorzertifizierung von Modulen ohne metallische Schirmung überhaupt nicht möglich. Wird ein Modul ohne metallische Schirmung verwendet, sollte dringend geprüft werden was diese Entscheidung hinsichtlich der Kosten für die Länderzulassung bedeutet.

Vorinstallierter Stack gegen eigene Bluetooth Firmware

Die Nutzung eines vorinstallierten Bluetooth Stack kann einem viel Ärger ersparen. Gerade im Bereich der Medizintechnik bietet ein vorinstallierter Bluetooth Stack einen wichtigen Vorteil: Der Aufwand für die Dokumentation sinkt enorm. Das mag erst einmal nicht so gravierend klingen. Man sollte aber im Hinterkopf behalten, dass eine eigene Bluetooth Firmware ein zusätzliches Softwareprojekt bedeutet, welches entsprechend der regulatorischen Vorgaben zu entwickeln und zu dokumentieren ist. Hinzu kommt, dass durch die Nutzung eines vorinstallierten Stacks in der Regel deutlich geringere Entwicklungskosten anfallen und keine kostenpflichtigen IDEs oder Compiler verwendet werden müssen.

Ihr Ansprechpartner:

M.Sc. Björn Schmitz, Software Entwickler
E-Mail: schmitz@medtech-ingenieur.de
Tel.:  +49 9131 691 240
 

Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf.

Kontakt aufnehmen


Der Vorteil einer eigenen Bluetooth Firmware liegt in der deutlich höheren Flexibilität. Vor allem wenn der Bluetooth Chip ohne Host Controller betrieben wird.

 

Datenrate

Das ist eines der am meisten missverstandenen Eigenschaften von BLE. Man liest hier immer wieder den Wert 1 Mbit/s, was natürlich schon ziemlich gut klingt. Leider ist dieser Wert aber vollkommen falsch. Ich werde es an dieser Stelle vermeiden zu tief in das BLE-Protokoll einzusteigen. Um ein grundsätzliches Verständnis dafür zu erhalten warum 1 Mbit/s fern von allem ist was man mit BLE (inklusive dem neuen Standard Bluetooth 5.0) erreichen kann, muss man eigentlich nur folgendes Wissen:

  • 1 Mbit/s ist die Bitrate von BLE-Transmittern (bei BT 5.0 ist außerdem 2 Mbit/s wählbar). Wer sich aber schon mal irgendwann mit irgendeinem Kommunikationsprotokoll beschäftigt hat, sollte wissen, dass es immer einen gewissen Overhead im Protokoll gibt.

  • Jetzt könnte man hingehen und die netto Datenrate aus Bitrate und Nutzdaten pro Paket berechnen. Würde man das tuen, hätte man immer noch mehr als 900 kbit/s, was ja auch immer noch echt gut klingt… Aber leider auch immer noch falsch ist.
  • Nun muss man noch wissen, dass BLE Central und Peripheral Device immer abwechselnd kommunizieren müssen. Selbst wenn das Central Device gerade nichts mitzuteilen hat, muss es mindestens ein leeres Paket senden. Zwischen jedem Paket gibt es dann noch einen Abstand. Geht man also davon aus das ein Gerät immer die volle Menge Nutzdaten überträgt, während das andere nur ein leeres Paket überträgt kommt man, wenn man den Abstand zwischen den Paketen mit einrechnet immer noch auf rund 800 kbit/s. Das ist jetzt das, was theoretisch mit BT 4.2 möglich ist. Leider sieht die Realität meistens deutlich anders aus.
  • Die BLE-Kommunikation findet während so genannter „Connection Intervalls“ statt. In diesen Intervallen tauschen die BLE-Geräte Daten miteinander aus. Laut BLE Spezifikation darf dieses Connection Interval minimal 7.5 ms betragen und kann in 1,25 ms Schritten erhöht werden. Theoretisch kann ein Connection Intervall mehrere Sekunden dauern. Das Problem ist, das bis zum Ende des Connection Intervall alle Kommunikation abgeschlossen sein muss. Das heißt, die Wiederkehrende Reihenfolge aus …
    1. Paket Central an Peripheral
    2. Pause
    3. Paket Peripheral an Central
    4. Pause

… muss abgeschlossen werden. Wäre also zu einem bestimmten Zeitpunkt noch Platz für ein Paket von Central an Peripheral, aber nicht mehr für die übrigen 3 Schritte werden keine weiteren Daten ausgetauscht. Ab hier beginnt das Glaskugellesen. Es ist kaum abzuschätzen wie viele Bytes, wann von Central an Peripheral übertragen werden. Das ist stark abhängig von der Implementierung des BLE-Stacks. Dementsprechend kann man nur schwer vorhersehen wie viele Pakete in einem Intervall ausgetauscht werden können. Außerdem ist die Anzahl der maximalen Pakete in einem Intervall bei den meisten Stack-Implementierungen begrenzt.

  • Hinzu kommt das BLE sich nicht besonders gut mit anderen Nutzern des 2,4 GHz Frequenzbandes versteht. Besonders schlecht steht es um die Beziehung mit dem allgegenwärtigen WLAN. Dieses kommuniziert nicht nur auf demselben Frequenzband, sondern überträgt zusätzlich mit einer deutlich höheren Leistung. BLE Daten sind auf Grund der geringen Sendeleistung anfällig für Störungen durch andere Teilnehmer auf dem Frequenzband. Kommt ein Paket hierdurch korrumpiert am Receiver an, wird jede weitere Kommunikation in diesem Connection Intervall eingestellt.

Lange Rede kurzer Sinn: Die Datenrate von BLE ist unter realistischen Bedingungen nur schwer vorher zu sagen und in der Regel deutlich geringer als die Bitrate 1 Mbit/s. Ich denke, dass man in einer einigermaßen „sauberen“ Umgebung mit einer Übertragungsrate von 100 kbit/s durchaus rechnen kann. Mehr bis hin zu den theoretisch erreichbaren 800 kbit/s ist möglich. Man sollte sich aber im Klaren sein, dass solche Werte wirklich nur erreicht werden, wenn man sich knietief in das BLE-Protokoll und die verwendete Stack-Implementierung vergräbt.

Latenz

Das ist so ziemlich der größte Nachteil in BLE. Im Kapitel „Datenrate“ wurden bereits die sogenannten Connection Intervals angesprochen. Diese regeln, wie oft ein BLE-Gerät mit seiner Gegenstelle kommunizieren darf. Theoretisch können während des ganzen Connection Intervals Daten ausgetauscht werden. Das Problem ist: Stehen zu Beginn des Intervalls keine Daten zur Verfügung, endet der Datenaustausch für diesen Intervall, nachdem beide Geräte ein leeres Paket an ihren Partner übertragen haben. Je nachdem wann Bluetooth Daten zum Senden an den Bluetooth Stack übergeben werden, kann es daher sein, dass es ein volles Intervall dauert, plus die Zeit, die es braucht, um die Daten  zu übertragen.

Hierdurch ergibt sich eine gewisse Variabilität in der Latenz, welche es kaum vorhersehbar macht, wann Daten, die zum Versenden bereit stehen, wirklich an der Gegenstelle ankommen. Schlägt eine Datenübertragung fehl, z.B. auf Grund von Störungen durch andere Teilnehmer aus dem Frequenzband, kann sich diese Variabilität um ein Vielfaches erhöhen. Das folgende Video zeigt ein Beispiel für die Latenz einer BLE Übertragung. Bei diesem Versuch wurden Daten in einem festen Raster an ein BLE Modul übertragen (gelbe Linie). Anschließend wurde der zeitliche Versatz gemessen, wann das Empfänger-Modul die Daten weitergibt (grüne Linie). Trotz Connection Interval von 7,5, ms lag die maximale Latenz hierbei nahezu doppelt so hoch.

Zusammengefasst kann man sagen, dass die Latenz einer BLE-Datenübertragung immer einer gewissen Variabilität unterliegt. Die maximale Latenz kann man durch die Wahl des Connection Intervals beeinflussen. Unter realistischen Bedingungen würde ich allerdings nicht von Intervallen deutlich kleiner als 20 ms ausgehen. Damit kann man in der Regel leben. Man sollte sich aber im Klaren sein, dass man nie mit vollständiger Sicherheit sagen kann, wie lange es dauert bis Daten über BLE übertragen werden. Das macht genaue Synchronisierung zweier BLE-Geräte und die Übertragung von Daten in Echtzeit nur schwer möglich.

BT 4.0 / 4.2 / 5.0 – Alles das gleiche?

Im Grunde stimmt das. BLE ist nun mal BLE. Ein gängiges Missverständnis ist, dass in der Spezifikation von Bluetooth 4.0 ausschließlich BLE enthalten ist. Tatsächlich handelt es sich bei BLE nur um eine Erweiterung des Bluetooth Protokolls, welche seit Version 4.0 hinzugefügt wurde und in den nachfolgenden Versionen weiterentwickelt wurde. Trotzdem ist auch das klassische Bluetooth nach wie vor in der Spezifikation enthalten.

Die Paketstruktur und wie diese ausgetauscht werden ist für BLE in allen Versionen sehr ähnlich. Das macht die Standards (teilweise) rückwärtskompatibel. Trotzdem gibt es gravierende Unterschiede. Hier drei der – aus meiner Sicht – wichtigsten:

  1. Secure Pairing: Das ist wohl einer der wichtigsten Neuerungen die BT 4.2 mit sich brachte. Durch neue Pairing-Mechanismen wurde BLE endlich einigermaßen sicher.
  2. Paketgröße: Hier hat sich ebenfalls etwas getan. Bei BT 4.2. konnte ein BLE Paket bei BT 4.0 gerade mal 27 Bytes Nutzdaten enthalten, waren es bei BT 4.2 schon 251 Nutzbytes. Es sollte jedoch darauf hingewiesen werden, dass mit größeren Paketen auch die Anzahl der Pakete pro Connection Intervall sinkt. Trotzdem wurde die Datenrate deutlich erhöht, da bei durchgängigen Datenstreams von A nach B, weniger leere Pakete von B nach A benötigt werden (siehe oben). Außerdem gibt es weniger Pausen, welche zwischen jedem Paket eingehalten werden müssen.
  3. Bitrate: Die größte Änderung von BT 5.0 ist, dass die Bitrate nun konfigurierbar ist. Statt den üblichen 1 Mbit/s lassen sich nun auch 2 Mbit/s einstellen. Zusätzlich übertragen BT 5.0 fähige Geräte mit deutlich höherer Leistung was zu einer erhöhten Reichweite führt. Da die höhere Datenrate allerdings zu einer geringeren Sensitivität des Receivers führt, hat man effektiv die Wahl zwischen zwei Möglichkeiten:
    • Man Überträgt mit (fast) doppelter Datenrate und ähnlicher Reichweite wie BT 4.2
    • Man Überträgt mit derselben Datenrate, aber dafür mit deutlich erhöhter Reichweite

Erwähnenswert ist außerdem, dass durch die höhere Bitrate bei hohen Datenmengen auch die Latenz sinken kann. Zwar liegt der minimale Connection Interval nach wie vor bei 7,5 ms, allerdings können nun deutlich mehr Pakete pro Interval übertragen werden.

Datensicherheit

BLE-Kommunikation findet in der Regel verschlüsselt statt. Eine Ausnahme stellen gewisse Daten, welche während dem Pairing ausgetauscht werden dar. Wie sicher eine BLE-Verbindung ist, steht und fällt mit dem verwendeten Pairing Mechanismus. Seit BT 4.2 gibt es die so genannten Secure Connections. Wie der Name erahnen lässt, wurde BT durch diese Mechanismen deutlich sicherer. Vor allem im Medizinbereich würde ich daher von der Verwendung der alten Legacy Connections abraten. Zum Glück unterstützen heute fast alle BLE-Geräte auf dem Markt Secure Connections. Der Unterschied im neuen Standard besteht im Protokoll, mit dem Schlüssel bei Pairing ausgetauscht werden. Hierfür wird seit 4.2 das Elliptic Curve Diffie-Hellman (ECDH) Verfahren angewendet, was die Sicherheit des Pairing Prozesses deutlich erhöht hat.

Leider werden trotzdem immer wieder Sicherheitslücken von BLE-Geräten bekannt. Diese resultieren allerdings in der Regel weniger aus der BT-Spezifikation, sondern sind in der Regel Folge einer mangelhaften Implementierung des Pairings. Wenn man den Einsatz von BLE im Medizinbereich plant, sollte man daher die Möglichkeit vorsehen, Bluetooth Hardware mit einem Update zu versehen, für den Fall, dass Sicherheitslücken bekannt werden.

Außerdem ist bei BLE Pairing nicht gleich Pairing. Seid BT 4.2 gibt es 4 verschiedene Pairing Mechanismen, welche jeweils ein unterschiedliches Maß an Sicherheit bieten.

  • Just WorksTM: Wie der Name vermuten lässt, handelt es sich hierbei um einen einfachen, gleichzeitig aber vergleichsweise unsicheren Pairing Mechanismus, auch wenn die Sicherheit des Mechanismus im Vergleich zum alten BT 4.0 Standard deutlich erhöht wurde.
  • Out of Band: Bei diesem Mechanismus wird ein großer Teil der Daten beim Pairing über eine alternative Verbindung ausgetauscht. Hierbei kann es sich z.B. über eine kabelgebundene Verbindung handeln. Zu beachten ist, dass dieser Mechanismus nur dann Sicherheit bietet, wenn der alternative Kanal nicht abgehört wird.
  • Passkey: Bei diesem Verfahren erhalten beide Geräte einen 6-stelligen Code, welcher zur Authentifizierung der Verbindung dient. Das Verfahren wurde ebenfalls im Standard BT 4.2 deutlich sicherer gestaltet, bietet aber nach wie vor ein gewisses Risiko, besonders wenn statische Codes verwendet werden.
  • Numeric Comparison: Dieses Verfahren ähnelt dem Just WorksTM, bietet allerdings eine erhöhte Sicherheit durch Hinzufügen eines weiteren Schritts am Ende des Pairings. Bei diesem berechnen beide Geräte einen 6-stelligen Code, welcher dem Nutzer auf den Displays der Geräte angezeigt wird. Der Nutzer muss nun auf beiden Geräten bestätigen, dass die Codes gleich sind. Diese Methode bietet einen erhöhten Schutz vor Angriffen, setzt aber das Vorhandensein von Displays auf beiden Geräten voraus.

Welche Pairing Methode gewählt wird hängt vom Anwendungsszenario und den daraus resultierenden Sicherheitsanforderungen ab. Werden sicherheitskritische oder personenbezogene Daten ausgetauscht, sollte man sich gut mit den jeweiligen Vor- und Nachteilen der jeweiligen Mechanismen auseinandersetzen.

Möchten Sie BLE einsetzen und haben dazu Fragen? Dann freuen wir uns, wenn wir Sie bei dem Thema unterstützen können. Nutzen Sie gerne unser Know-how an dieser Stelle.

Viele Grüße

Björn Schmitz


Geschrieben von Björn Schmitz

Seit Juli 2017 gehöre ich zum MEDtech-Ingenieur Team und bin hier vor allem als Firmwareentwickler tätig. Schon in kürzester Zeit konnte ich an vielen spannenden Projekten aus dem Bereich Medizintechnik, aber auch aus anderen Bereichen mitwirken.


Weitere Beiträge

  • 29/01/2025
  • Allgemein, Hardware, Testen

Einleitung Um bei der EMV Prüfung für die Zulassung neuer medizintechnischer Geräte das Risiko zu reduzieren machen wir gerne Vortests mit den Geräten in der Prototypen Phase. Aktuell unterstützen ...

Weiterlesen
  • 12/11/2024
  • Allgemein, Software, Testen, Tools

In sicherheitskritischen Softwareprojekten steht die Qualität der Software an erster Stelle. Besonders bei Klasse-C-Software, die nach strengen Normen wie IEC 62304 (Medizintechnik) zertifiziert werden muss, ist es essenziell, dass ...

Weiterlesen
  • 12/09/2024
  • Allgemein, Fertigung, Hardware, Qualität

Die Schnellen fressen die Langsamen – die Bedeutung der schnellen Prototypenfertigung in der Elektronikentwicklung Unsere Bestückungsmaschine erlaubt uns kleinere Chargen manuell und wesentlich schneller zu bestücken. In der Elektronikbranche ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies