Niedrige Latenzen mit Bluetooth Low Energy

Björn Schmitz

10/03/2021

Bluetooth Low Energy (BLE) hat sich in den letzten Jahren zu dem Kommunikationsstandard für stromsparende kabellose Kommunikation entwickelt. In den Anfangszeiten war BLE vor allem in Consumer-Anwendungen vertreten. Wir haben in vergangenen Projekten allerdings festgestellt, das BLE inzwischen auch in der Welt der Medizinprodukte angekommen ist. Der Einsatz bei körpernaher Sensorik liegt nahe, da bei den hier verwendeten Sensorknoten meistens Batterielaufzeit entscheidend ist. Wir haben allerdings festgestellt, dass auch zunehmend kritischere Signale über BLE übertragen werden. Oft ist dabei ein Parameter besonders im Fokus: Die Latenz. Wenn ich in diesem Artikel von Latenz spreche meine ich den zeitlichen Abstand zwischen dem ersten Versuch einer Übertragung (das Übergeben der Nachricht an den BLE Stack), zum Empfangen der Nachricht beim Verbindungspartner (Übergabe der Nachricht vom BLE Stack an die Applikation).

Dieser Artikel bespricht:

  • Wodurch entstehen Latenzen bei der BLE Kommunikation?
  • Welche Parameter haben Einfluss auf die Latenz?
  • Welche Latenz kann ich mit BLE erreichen?
  • Welche Nachteile hat eine auf Latenz optimierte BLE Kommunikation?
  • Wie gehe ich mit Latenzen in Sicherheitskritischen Bereichen um?

Wer noch nicht viel Erfahrung mit dem Thema BLE hat, dem empfehle ich einen Blick in einen älteren Blog-Artikel von mir:

https://medtech-ingenieur.de/ble-ein-kurze-einstiegshilfe-in-die-welt-von-bluetooth-low-energy/

Hier werden einige Grundlagen zu BLE besprochen. Da wir in diesem Artikel tief in BLE einsteigen empfiehlt es sich, sich vorher mit den Grundlagen vertraut zu machen.

Da das Thema Latenz doch etwas komplex ist, ist dieser Artikel ziemlich lang geraten. Ich habe daher versucht die wichtigsten Punkte hervorzuheben. Wer also wenig Zeit hat kann sich zunächst auf die hervorgehobenen Texte fokussieren.

Wer allerdings verstehen möchte warum eine bestimmte Einstellung getroffen werden sollte, dem bleibt leider nichts anderes übrig als den ganzen Artikel zu lesen.

Warum sollte ich mich überhaupt mit der Latenz von BLE Verbindungen beschäftigen?

Ich kenne viele sehr interessante Artikel die sich eingehend mit dem Thema Datendurchsatz bei BLE beschäftigen. Ich kenne allerdings wenig Artikel, die sich mit der Optimierung von Latenzen beschäftigen. Eine optimierte Latenz führt nicht unbedingt zu einer hohen Datenrate und andersherum. Gerade in sicherheitskritischen Bereichen wie der Medizintechnik werden zum Teil wenig Daten übertragen. Dafür ist oft die Zeit mit der eine einzige Nachricht übertragen wird entscheidend. Stellen wir uns folgendes (zugegebenermaßen sehr weit hergeholte) Szenario vor:

Ein Defibrillator soll über eine kabellose Fernbedienung gesteuert werden. Die Fernbedienung hat einen Knopf, mit dessen Hilfe der behandelnde Arzt einen Schock auslösen kann. Der Knopf soll natürlich nur freigeschaltet werden, wenn der Defibrillator einen schockbaren Rhythmus im EKG erkennt. Um den Nutzer dies zu signalisieren, wird eine LED verwendet die dem Nutzer anzeigt, wann der Knopf aktiv ist.

Entscheidend ist, dass bei dieser Anwendung nicht das ganze EKG, inklusive aller Rohdaten, an die Fernbedienung übertragen werden muss. Eine hohe Datenrate ist von Defibrillator zu Fernbedienung also nicht erforderlich. Die Fernbedienung benötigt lediglich die Information, dass sie die LED an oder ausschalten muss. In der anderen Richtung muss die Fernbedienung dem Defibrillator nur die Information „Knopf wurde gedrückt“ senden. Diese Information ist nicht sehr komplex und benötigt daher ebenfalls keine hohe Datenrate. In beiden Fällen spielt jedoch die Latenz eine große Rolle. Verzögert sich eine der beiden Informationen, wird die Behandlung des Patienten hinausgezögert, wodurch wichtige Zeit verstreicht. Wie schon erwähnt ist das beschriebene Beispiel nicht unbedingt sinnvoll, sondern soll nur erläutern, warum Latenz manchmal wichtiger als Datenrate ist.

Wodurch Latenzen bei BLE entstehen…

Um zu verstehen, wo das Problem bei BLE und Latenz liegt, sollten wir uns zunächst anschauen, was BLE überhaut „low energy“ macht. Im Unterschied zum klassischen Bluetooth sind BLE Verbindungen niemals „konstant offen“. Es handelt sich also nicht um einen konstanten Datenstrom zwischen A und B. Anstatt dessen bauen A und B in bestimmten Intervallen ihre Verbindung auf und wieder ab. Diese Intervalle sind die sogenannten „Connection Intervals“ (CI).

Innerhalb eines CIs haben Central und Peripheral die Möglichkeit Daten auszutauschen. Selbst wenn keine Daten ausgetauscht werden sollen, senden Central und Peripheral immer mindestens ein leeres Paket, um dem gegenüber zu signalisieren, dass Sie noch da sind. Hat keiner der beiden Partner noch etwas zu sagen, wird die Kommunikation bis zum Ende des CIs beendet. In diesem Fall müssen beide bis zum nächsten CI warten, bis Sie wieder Daten senden können. Durch das Abbauen der Verbindung wird der Stromverbrauch von BLE deutlich reduziert. Gleichzeitig bedeutet dieses Verhalten jedoch, dass man immer mindestens mit einem CI Latenz rechnen muss. Nehmen wir beim oben beschriebenen Beispiel an, das zu Beginn eines CIs ein schockbarer Rhythmus erkannt wird. Der Defibrillator möchte daher so schnell wie möglich den Befehl senden, die LED an der Fernbedienung zu aktivieren. Wurde die Verbindung allerdings bereits vom Central beendet, muss der Defibrillator mindestens einen CI warten, bis er senden kann. CIs sind konfigurierbar für jede Verbindung, können allerdings nicht weniger als 7,5 ms betragen.

Mit einer minimalen Latenz von 7,5 ms muss man daher in jedem Fall rechnen!

Außerdem sollte man noch wissen, dass BLE Nachrichten in gestörten Umgebungen nicht einfach so verloren gehen. Werden Pakete durch die Übertragung beschädigt, oder kommen diese gar nicht an, werden die Pakete grundsätzlich erneut übertragen. Dies findet in den untern Layern der BLE Architektur (Link Layer) statt. Es werden also dabei keine Nachrichten wiederholt sondern die physikalischen Pakete. Diese werden so lange erneut übertragen, bis sie entweder erfolgreich angekommen sind, oder die Verbindung durch einen der beiden Teilnehmer unterbrochen wird. Das Problem dabei: Kommt es zu einer Störung werden keine Daten mehr ausgetauscht bis zum nächsten CI. Durch das BLE Frequency Hopping Verfahren (mehr dazu weiter unten im Artikel), findet zwar jedes CI auf einer anderen Frequenz statt, so dass die Wahrscheinlichkeit recht hoch ist, dass ein Paket irgendwann auch ankommt, in der Praxis kommt es allerdings immer wieder zu mehreren Retransmissions hintereinander. Aus diesem Grund können Nachrichten gleich um mehrere CIs verzögert sein. Bei zwei Retransmissions kann man davon ausgehen das es 3 CIs braucht (also 22,5 ms) bis die Nachricht empfangen wird. Auf Grund der Retransmissions lässt sich also sagen:

Wenn wir bei BLE über Latenz reden dann handelt es sich lediglich um die minimale Latenz. Die Garantie, unter einer maximalen Latenz zu bleiben, gibt es nicht. Es lässt sich lediglich die Wahrscheinlichkeit reduzieren, dass hohe Latenzen entstehen.   

Das ist etwas ernüchternd, ich werde aber in den kommenden Kapiteln darauf eingehen wie man zumindest die minimale und durchschnittliche Latenz so gering wie möglich halten kann.

Wie lässt sich die Latenz optimieren?

Der Connection Interval

Wie oben beschrieben bestimmt der CI maßgeblich die minimale Latenz der Verbindung.

Sofern es die genutzte Hardware, sowie der BLE Stack erlaubt, sollte man den Connection Interval der Verbindung auf 7,5 ms setzen.

Auf Smartphones beispielsweise, ist der kleinste CI in der Regel deutlich höher als 7,5 ms.

Slave Latency

Ein weiterer entscheidender Parameter ist die sogenannte Slave Latency (SL). Diese bestimmt eine Zahl von CIs, während der sich der Peripheral nicht beim Central melden muss, bevor der Central ein Problem annimmt. Grundsätzlich macht die Nutzung der SL dann Sinn, wenn ein geringer Stromverbrauch wichtig ist (also eigentlich immer).  Im vorherigen Kapitel wurde der Austausch von Paketen bei BLE beschrieben. Bei einer Slave Latency von 2, würde man, im Fall, dass es keine Daten zum Austausch gibt, folgende Kommunikation beobachten:

In diesem Fall muss der Peripheral in zwei aufeinanderfolgenden CIs weder Daten senden, noch empfangen. Hierdurch ergibt sich ein enormes Stromsparpotential. Vor allem, wenn SL sehr hoch gewählt wird. Allerdings muss man in diesem Fall bei der Latenz von Central zu Peripheral bis zu 3 CIs annehmen. Schließlich kann es ja immer sein, dass das Peripheral gerade nichts zu sagen hat und daher 2 Verbindungen aussetzt. Man sollte allerdings erwähnen, dass ein Peripheral immer Daten senden kann, wann es möchte. Die Latenz verschlechtert sich daher nur in eine Richtung.

Man kann sich also Merken:

Hat man hohe Anforderung an die Latenz von Central zu Peripheral sollte man die Slave Latency auf null setzten.

Sind die Anforderungen an die Latenz von Central zu Peripheral nicht so hoch, macht die Nutzung der SL allerdings Sinn. Außerdem: SL kann natürlich auch dynamisch angepasst werden. So kann man für gewisse Situationen, in denen keine (sicherheitskritische) Datenübertragung von Central zu Peripheral zu erwarten ist, die SL hochsetzen, um Strom zu sparen.

Protokollebene

Neben Central und Peripheral, gibt es bei BLE die Einteilung in Client und Server. Das Central übernimmt dabei meisten (aber nicht immer) die Rolle des Clients, während das Peripheral die Serverrolle übernimmt. Der Server definiert im GATT (Generic Attribute Profile) Layer Services, auf die der Client zugreifen kann. Den GATT Layer komplett zu erklären würde den Rahmen dieses Artikels sprengen. Ganz gut beschrieben wird das zum Beispiel hier:

https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt

Um das ganze etwas zusammenzufassen: GATT bestimmt, wie BLE Geräte miteinander kommunizieren, schließlich handelt es sich um das Kommunikationsprofil von BLE. Ähnlich tut es z.B. auch das etwas bekanntere SPP (serial port profile), auch wenn dieses komplett anders funktioniert. Bei BLE findet der Datenaustausch über sogenannte Services statt. Diese haben Charakteristiken die wiederum Properties haben. Services sind Gruppen von Charakteristiken. Charakteristiken sind vereinfacht ausgedrückt Datenfelder des Servers. Als Beispiel, der Heart Rate Service hat eine Heart Rate Measurement Charakteristik, sowie eine Body Sensor Location Charakteristik (und noch weitere die ich daher an dieser Stelle nicht erwähnen werde). Durch Lesen der Heart Rate Measurement Charakteristik erhält man die Herzrate. Durch Lesen der Body Sensor Location Charakteristik erhält man den Ort, an dem der Sensor getragen werden soll (Ist das Gerät z.B. ein Brustgurt oder eine Uhr). Die Herzrate lässt sich außerdem abonnieren, was dazu führt, dass der Client für jede Änderung in der Herzrate eine Nachricht erhält.

Wie man auf Charakteristiken zugreifen kann, regeln die Properties, also Eigenschaften der Charakteristik:

Propertie Erläuterung
Write without response Schreiben einer Charakteristik (Client überträgt Daten an das Peripheral). Die Charakteristik hat hinterher den Wert, welcher vom Client gesendet wurde.
Write Wie „write without response“, nur dass in diesem Fall das Peripheral die Antwort quittieren muss. Der BLE Stack reicht die Nachricht an die Applikation des Peripherals weiter, diese muss die Nachricht bestätigen. Anschließend wird die Antwort gesendet. Der Client kann keinen weiteren Wert schreiben bevor, er die Antwort nicht erhalten hat.
Notification Charakteristiken mit dieser Propertie können vom Client abonniert werden. Anschließend sendet der Server eine Nachricht an den Client, wann immer sich der Wert der Charakteristik ändert (oder einfach in bestimmten Intervallen).
Indication Wie Notification, aber mit dem Unterschied, dass Indications bestätigt werden müssen bevor eine neue Indication gesendet werden kann. Der Unterschied zwischen Notification und Indication verhält sich damit ähnlich wie der Unterschied zwischen write und write without respons. Nur eben anders herum.
Read Lesen einer Charakteristik. Der Client sendet eine Anfrage an den Server, dieser antwortet anschließend mit dem aktuellen Wert der Charakteristik.

Um Latenzen zu reduzieren macht es Sinn, die korrekten Properties auszuwählen.

In der Regel fährt man mit write without response für Übertragungen von Client zu Server, sowie notifications für Übertragungen von Server zu Client am besten.

Da diese Properties nicht bestätigt werden müssen, können die entsprechenden Aktivitäten deutlich schneller hintereinander ausgeführt werden. Wie ja schon erwähnt gehen BLE Nachrichten auch ohne Response nicht einfach verloren.  Write und Indications bieten lediglich eine Möglichkeit auf einer höheren Ebene als dem Link Layer unberechtigte oder falsche Zugriffe abzulehnen (Beispiel: Client schreibt einen ungültigen Wert in die Characteristik). Für die Absicherung der BLE Übertragung bringt der Vorgang keine weitere Sicherheit.

Übertragung von unnötigen Daten vermeiden

Wie beschrieben, werden BLE Pakete so lange erneut übertragen, bis diese angekommen sind oder die Verbindung beendet wird. So etwas wie eine maximale Anzahl an Retransmissions ist im BLE Standard nicht vorgesehen. Das ist gut, wenn man sicher gehen will, dass alle Informationen die man senden möchte auch auf der Gegenstelle ankommen. Auf der anderen Seite blockieren Retransmission neue Übertragungen, da es keine Möglichkeit gibt Nachrichten zu priorisieren. In einer gestörten Verbindung kann es durchaus zu mehreren Retransmissions einer Nachricht kommen. Sendet man in so einer Umgebung mit zu hoher Datenrate, stauen sich irgendwann die Nachrichten und es kommt der Punkt, an dem der BLE Stack die Annahme von weiteren Nachrichten ablehnt.

Es empfiehlt sich daher in Sicherheitskritischen Bereichen wirklich nur die unbedingt notwendigen Nachrichten zu senden.

So vermeidet man, dass wichtige Nachrichten auf unwichtige warten müssen.

Viele BLE Stacks bieten zudem eine Möglichkeit, die Anzahl der maximalen Elemente in den Queues für Notification und Write Prozesse zu konfigurieren. In der Regel sind Daten, die einmal an den BLE Stack übergeben wurden, nicht mehr zu stoppen. Würde man die Queue also zu groß wählen, könnten sich in gestörten Umgebungen große Mengen an Daten im Stack anstauen. Daher empfiehlt sich oft ein niedriger Wert, so dass der BLE Stack in gestörten Umgebungen früh anfängt Nachrichten abzulehnen. Wenn dies geschieht können die abgelehnten Nachrichten auf Anwendungseben zurückgehalten werden und durch aktuellere oder höher priorisierte Nachrichten ersetzt werden.

Außerdem empfiehlt es sich die Nachrichten so kurz wie möglich zu halten.

In einem BLE Paket können mehrere Nachrichten enthalten sein. So kann der BLE Stack mehrere Elemente seiner Queue auf einmal versenden. Andererseits können sich Nachrichten auch über mehrere Pakete erstrecken. Kommt es dabei zu Retransmissions eines oder mehrerer Pakete kann die Übertragung sehr lange dauern.

Retransmissions reduzieren (Bluetooth 5)

Wenn man auf Protokollebene und mit Hilfe korrekter Bluetooth Parameter bereits die Latenzen optimiert hat, wird es trotzdem immer wieder vorkommen, das Pakete verzögert ankommen. Schuld daran sind die Retransmissions die man niemals ganz ausschließen kann. Was kann man dagegen tun? Insgesamt sind die Möglichkeiten hierzu nicht sehr vielseitig. Seit Bluetooth 5.0 hat man aber zumindest diese beiden Möglichkeiten:

Möglichkeit 1: Adaptive Frequency Hopping.

BLE verwendet seit Bluetooth 4.0 grundsätzlich Frequency Hopping. Jeder CI findet auf einem anderen Frequenzband statt. Das Muster, nach dem die Geräte auf den Frequenzen springen wird pseudo-zufällig bei jeder neuen Verbindung festgelegt (berechnet sich unter anderem aus den Bluetooth Adressen von Central und Peripheral). Bluetooth 5.0 fügt ein so genanntes adaptive Frequency hopping hinzu. Hierbei monitored der BLE Stack kontinuierlich die Frequenzen auf denen er kommuniziert. Kommt es auf einem der Frequenzbänder zu einer Störung, wird dieses Band vorübergehend deaktiviert. Der Central erstellt so immer wieder eine neue Channel Map und überträgt diese nach jedem Update an das Peripheral. Das ist ziemlich praktisch, allerdings gibt es ein entscheidendes Problem: Viele Hersteller von BLE Stacks unterstützen kein Adaptive Frequency Hopping. Die Nordic Soft Devices z.B. können dies nicht und erfassen auch gleichzeitig keine Informationen, um etwas entsprechendes selber zu implementieren. Silicon Labs hingegen unterstützt das Feature seit Bluetooth SDK Version 2.10.

Möglichkeit 2: Auswahl des korrekten PHYs.

PHY steht hier für den physikalische Layer von BLE, beschreibt also den untersten Layer der BLE Architektur der für das Versenden und Empfangen von BLE Paketen zuständig ist. In der Regel arbeitet der Layer dabei mit einer Bitrate von 1 MHz. Seit Bluetooth 5.0 sind folgende Einstellungen hinzugekommen:

  • 2 MHz
  • Coded PHY 500 kHz
  • Coded PHY 125 kHz

Während die schnellere Einstellung vor allem dazu genutzt werden kann die Datenrate hochzukurbeln, sind die beiden langsameren Einstellungen vor allem für eine höhere Reichweite gedacht. Jetzt könnte man denken „schneller ist immer besser!“. Das Problem dabei ist allerdings das die Reichweite bei dieser Einstellung deutlich reduziert wird. Aus diesem Grund sinkt zwar die minimale Latenz (zumindest etwas), die maximale Latenz steigt allerdings. Meiner Meinung macht dieses Feature Sinn für FW Updates (wofür es auch gedacht ist). In sicherheitskritischen Bereichen würde ich es nicht unbedingt empfehlen. Interessanter sind tatsächlich die langsameren Einstellungen (Coded Phy). Hier wird die Nachricht nicht einfach langsamer gesendet, sondern (fast) jedes Bit wird tatsächlich mehrfach (bei 125 kHz 8 mal) gesendet. Dadurch erhält der Empfänger mehr Möglichkeiten zur Fehlerkorrektur, wodurch Retransmissions vermieden werden und die Wahrscheinlichkeit für sehr hohe Latenzen deutlich geringer wird. Auch hier ist aber wieder das Problem einen Stack Hersteller zu finden, der alle Einstellungen unterstützt. Während das Silicon Labs SDK alle Einstellungen unterstützt, können die Nordic Sofdevices zwar auf allen Einstellungen empfangen aber nur auf 125 kHz senden. Das ist schade, schließlich steigt der Stromverbrauch bei 125 kHz deutlich da ja jedes Bit 8 mal übertragen und empfangen werden muss. Gleichzeitig wird auch die Datenrate deutlich geringer. Die Einstellung eignet sich also nur dann, wenn man wirklich sehr geringe Datenmengen versenden will. Im Vergleich dazu bietet 500 kHz Coded Phy einen guten trade off.

Und was wenn ich immer noch gelegentlich hohe Latenzen messe?

Wie bereits erwähnt kann ich eine maximale Latenz zwar über einen längeren Zeitraum messen, aber niemals garantieren. Erhöht sich der Abstand zwischen 2 Geräten oder kommt es zu Störungen auf dem 2,4 GHz Band, steigt die maximale Latenz. In Sicherheitskritischen Bereichen ist es daher sinnvoll Maßnahmen auf Applikationsebene zu implementieren, die zumindest Störungen erkennen. Im oben beschriebenen Beispiel mit dem Defibrillator, würde es Sinn machen den Zustand des Schockknopfs in regelmäßigen Intervallen zu versenden. Kommen die Nachrichten regelmäßig an weiß der Defibrillator das alles in Ordnung und der Knopf nicht gedrückt ist. Falls die Nachrichten für längere Zeit ausbleiben, kann der Defibrillator zumindest den Nutzer alarmieren. Grundsätzlich sollte man immer ein Back Up für das angebundene BLE Gerät haben. Im Fall des Defibrillators kann dies z.B. ein zusätzlicher Schockknopf direkt am Gerät sein.

Und was sind die Nachteile?

Auf Latenz optimierte Verbindungen sind nicht unbedingt optimiert auf Datendurchsatz. Verwendet man z.B. Coded PHY leided immer die Datenrate darunter. Auch der CI muss für schnellen Datendurchsatz in der Regel nicht auf 7,5 ms eingestellt werden. Oft ist es besser lange Intervalle zu wählen, damit während einem Datenstream, die Verbindung nicht dauernd auf und wieder abgebaut wird. Für Vorgänge bei denen hohe Datenraten benötigt werden, muss ggf. ein zusätzlicher Modus implementiert werden, in dem man die Verbindung stärker auf Datendurchsatz optimiert. Zum Glück lassen sich alle BLE Parameter während einer bestehenden Verbindung ändern.

Ebenfalls sollte man beachten, das auf Latenz optimierte Verbindungen einen hohen Stromverbrauch bedeuten können. Geringe CI und SL Parameter sowie Coded PHY wirken sich allesamt negativ auf den Stromverbrauch aus.


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

  • 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
  • 08/08/2024
  • Allgemein, Elektrostimulation, Software, Testen

Heutzutage sind Apps im Gesundheitsbereich sehr wichtig. Besonders Apps, die Daten von medizinischen Sensoren lesen und verarbeiten können, sind nützlich. Flutter ist ein Open-Source-Framework von Google, das sich hervorragend ...

Weiterlesen
  • 30/06/2024
  • Allgemein, Hardware, Software, Technik, Tools, Usability

KI – Was ist das denn überhaupt? Künstliche Intelligenz ist zurzeit in aller Munde, doch die wenigsten Menschen beschäftigen sich mit der Funktionsweise von künstlicher Intelligenz oder damit, was ...

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