DE60119125T2

DE60119125T2 - Kurze datennachrichten in mobilkommunikationssystemen

Info

Publication number: DE60119125T2
Application number: DE60119125T
Authority: DE
Inventors: Wentworth Mark Rayne; John Richard Travett
Original assignee: Sepura Ltd
Current assignee: Sepura Ltd
Priority date: 2000-08-17
Filing date: 2001-08-17
Publication date: 2006-11-09
Also published as: ATE324753T1; PT1310115E; DE60119125T8; GB0020323D0; EP1310115A1; DE60119125D1; ES2263644T3; WO2002017659A1; EP1310115B1; GB0120169D0; DK1310115T3; GB2369753B; GB2369753A

Description

Die vorliegende Erfindung betrifft die Übertragung von Kurzdatennachrichten in Mobilkommunikationssystemen und insbesondere die Übertragung verschlüsselter Kurzdatennachrichten.
Viele Mobilkommunikationssysteme unterstützen die Übertragung von Kurzdatennachrichten zusätzlich zur Sprachkommunikation, um beispielsweise verschiedene Typen von Daten, wie Ortsinformationen, Textnachrichten, Statusnachrichten (beispielsweise vom Funkbenutzer), Telemetriesowie Alarm- und Warnnachrichten zu übertragen. Der Kurzdatendienst-(SDS)-Mechanismus des TETRA-(TErrestrial Trunked RAdio)-Systems (siehe beispielsweise ETSI ETS 300 392-2) ist ein solches Kurzdatennachrichtenprotokoll. Der Kurznachrichtendienst (Short Message Service – SMS) des GSM-Systems (globales System für die Mobilkommunikation – Global System for Mobile communications) (siehe beispielsweise Michel Mouly und Marie-Bernadette Pautet "The GSM System for Mobile Communications", Cell & Sys, 1992 ISBN 2-9507190-0-7) ist ein anderes. Ein ähnlicher Kurznachrichtendienst ist bei analogen MPT-1327-Bündelfunksystemen verfügbar (siehe beispielsweise MPT 1327 DTI).
Es wird zunehmend wünschenswert, dass Benutzer solcher Kommunikationssysteme in der Lage sind, ihre Kurzdatennachrichtenübertragungen zu verschlüsseln. Einige Kommunikationssysteme, wie TETRA und GSM, stellen automatisch eine Verschlüsselung über die Luftschnittstellen verbindung bereit (wobei in TETRA der Standard-Luftschnittstellenmechanismus verwendet wird). Es wird jedoch zunehmend erwünscht, eine so genannte "Verschlüsselung von Ende zu Ende" bereitzustellen (d.h. die Kurzdatennachrichten über den gesamten Weg vom Sender zum Empfänger zu verschlüsseln), weil beispielsweise viele Benutzer, wie Benutzer öffentlicher Sicherheit, sich möglicherweise nicht auf die Sicherheit der existierenden Luftschnittstellenverschlüsselung allein verlassen möchten oder der Sicherheit der festen Infrastruktur möglicherweise nicht trauen.
Viele Kommunikationssysteme unterstützen jedoch die Verschlüsselung von Kurzdatennachrichten von Ende zu Ende möglicherweise nicht direkt. Wenngleich das TETRA-System beispielsweise eine Luftschnittstellenverschlüsselung der gesamten Kommunikationen und eine Verschlüsselung der Sprachkommunikation von Ende zu Ende bereitstellt, stellt der grundlegende TETRA-Standard beispielsweise nicht direkt eine Verschlüsselung von Kurzdatennachrichten von Ende zu Ende bereit.
In FI 990 256 A und WO 00/48416 A ist eine Kurzdatennachrichtenstruktur für ein Mobilkommunikationssystem beschrieben, welche ein Feld aufweist, das die Nachricht als verschlüsselt definieren kann.
Eine Aufgabe der vorliegenden Erfindung besteht darin, Mechanismen bereitzustellen, um dabei zu helfen, dass das TETRA-System eine Verschlüsselung von Kurzdatennachrichten von Ende zu Ende unterstützt.
Die Anmelder haben insbesondere erkannt, dass dort, wo eine Verschlüsselung von Kurzdatennachrichten von Ende zu Ende zu verwenden ist, ein Weg gegeben sein muss, um den Empfänger darauf hinzuweisen, dass die Nachricht einen verschlüsselten Benutzer oder eine erwünschte Nachricht enthält, um zu ermöglichen, dass der Empfänger die Nachricht geeignet verarbeitet.
Gemäß einem ersten Aspekt der vorliegenden Erfindung ist ein Verfahren zum Übertragen einer Kurzdatennachricht in einem TETRA-Mobilkommunikationssystem vorgesehen, bei dem, wenn die Kurzdatennachricht eine verschlüsselte Nachricht umfasst, ein Hinweis auf diese Tatsache in die Kurzdatennachricht aufgenommen wird, wobei das Verfahren ferner Verwenden bestimmter Protokollkennungswerte als Verschlüsselungshinweis und Bilden der Kurzdatennachricht umfasst, so dass sie die auf die Verschlüsselung hinweisende Protokollkennung, gefolgt von einem verschlüsselten Teil der Kurzdatennachricht mit einer Protokollkennung für die Nachricht, die verschlüsselt ist, und der verschlüsselten Nachricht, aufweist.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist eine Vorrichtung zum Übertragen einer Kurzdatennachricht in einem TETRA-Mobilkommunikationssystem vorgesehen, wobei die Vorrichtung umfasst: Mittel zum, wenn die Kurzdatennachricht eine verschlüsselte Nachricht umfasst, Aufnehmen eines Hinweises auf diese Tatsache in die Kurzdatennachricht, die Mittel zum Verwenden bestimmter Protokollkennungswerte als Verschlüsselungshinweis und Mittel zum Bilden der Kurzdatennachricht umfassen, so dass sie die auf die Verschlüsselung hinweisende Protokollkennung, gefolgt von einem verschlüsselten Teil der Kurzdatennachricht beinhaltend eine Protokollkennung für die Nachricht, die verschlüsselt ist, und die verschlüsselte Nachricht, aufweist.
Gemäß weiteren Aspekten der vorliegenden Erfindung sind eine entsprechende Kurzdatennachricht und ein Computerprogrammelement bereitgestellt.
Gemäß der vorliegenden Erfindung wird, wenn eine Kurzdatennachricht unter Einschluss einer verschlüsselten Nachricht übertragen wird, ein getrennter Hinweis auf diese Tatsache (über die bloße Tatsache, dass die Nachricht selbst verschlüsselt ist, und darüber hinaus) in die Kurzdatennachricht aufgenommen. Dies bietet einen zweckmäßigen Mechanismus, um den Empfänger auf das Vorhandensein einer verschlüsselten Nachricht in der Kurzdatennachricht hinzuweisen.
Der Verschlüsselungshinweis geht der verschlüsselten Nachricht voraus. Seine Position sollte dem Empfänger bekannt sein und ist daher vorzugsweise vorbestimmt, oder sein Ort wird dem Empfänger zuvor angegeben (beispielsweise in einer früheren Nachricht). Der Verschlüsselungshinweis wird vorzugsweise gegen Anfang der Nachricht angeordnet, wobei er beispielsweise einen Vorspann für die verschlüsselte Kurzdatennachricht bildet, und er geht vorzugsweise den Benutzerdaten in der Nachricht voraus, weil dies zweckmäßiger ist, wenn die Nachrichten eine veränderliche Länge aufweisen können (weil es hierdurch nicht nötig ist, Kurznachrichten unter diesen Umständen "aufzufüllen").
Der Verschlüsselungshinweis ist vorzugsweise nicht selbst verschlüsselt (um dem Empfänger zu ermöglichen, ihn zu lesen).
Der Verschlüsselungshinweis könnte stets vorhanden sein und zwei Zustände aufweisen, wodurch "verschlüsselte Nachricht" bzw. "unverschlüsselte Nachricht" angegeben wird. Alternativ könnte der Hinweis nur dann in die Nachricht aufgenommen werden, wenn sie verschlüsselt ist oder eine verschlüsselte Nachricht einschließt, jedoch ansonsten nicht (d.h. so dass eine unverschlüsselte Nachricht als normal gesendet wird).
Falls die Nachricht nicht verschlüsselt ist, würde der Verschlüsselungshinweis, falls vorhanden, auf "nicht verschlüsselt" gesetzt werden, und der Rest der Nachricht würde als normal angeordnet werden.
Falls die Nachricht verschlüsselt ist oder eine verschlüsselte Nachricht einschließt, würde der Verschlüsselungshinweis darin aufgenommen werden und auf "verschlüsselt" gesetzt werden. Die zu verschlüsselnde Nachricht würde verschlüsselt werden und in verschlüsselter Form in der Nachricht gesendet werden.
Die in verschlüsselter Form zu sendende Nachricht kann eine beliebige geeignete solche Nachricht sein, die normalerweise in einer Kurzdatennachricht gesendet werden würde, jedoch nicht notwendigerweise immer in verschlüsselter Form (und sie kann beispielsweise typischerweise bei der normalen Verwendung nicht von Ende zu Ende verschlüsselt sein und/oder würde beispielsweise nicht in einer verschlüsselten Form in dem fraglichen Kommunikationssystem zum Senden angewiesen werden). Sie wäre typischerweise eine Benutzernachricht und/oder eine Anwendungsnachricht in der Art einer Textnachricht, einer Statusnachricht, einer Positionsaktualisierung usw., wodurch Informationen (beispielsweise erwünschte Daten) zu einem anderen Benutzer des Systems und/oder Informationen von einem Endbenutzer oder einer Endbenutzeranwendung übermittelt werden oder übermittelt werden können, statt einer Nachricht, die Systemdaten übermittelt, wie eine OTAR-(Über-die-Luft-Umverschlüsselung)-Parameternachricht, die den Betrieb des Systems ermöglicht, jedoch keine Informationen korrekt zu einem Endbenutzer übermittelt.
Die in verschlüsselter Form zu sendende Nachricht kann nach Wunsch in die Kurzdatennachricht aufgenommen werden, die gesendet wird. Sie könnte beispielsweise durch Verschlüsseln der Originalbenutzernachricht (beispielsweise einer Textnachricht, einer Positionsaktualisierung, einer GPS-Nachricht usw.) gebildet werden, und die verschlüsselte Benutzernachricht könnte dann im "Benutzernachrichtenfeld" des Standard-Kurzdatennachrichtenformats angeordnet werden, wobei der Rest der Nachricht eine "normale" Kurzdatennachricht (und die gewöhnlichen Header usw. der Kurzdatennachricht umfasst) ist und mit Ausnahme des Vorhandenseins des Verschlüsselungshinweises in unverschlüsselter Form vorliegt.
Gemäß einer besonders bevorzugten Ausführungsform wird die in verschlüsselter Form zu sendende Nachricht jedoch zuerst in einem Teil einer normalen Kurzdatennachrichtenstruktur oder einer gesamten Kurzdatennachrichtenstruktur angeordnet, die einige oder alle der gewöhnlichen Kurzdatennachrichtensystem-Datenheader, -felder usw. aufweist (und vorzugsweise mindestens einen solchen Header oder ein solches Feld, wodurch Systembetriebsdaten übermittelt werden), und die so gebildete "normale" Kurzdatennachricht oder der so gebildete Kurzdatennachrichtenteil wird dann verschlüsselt und mit dem Verschlüsselungshinweis in die eigentliche Kurzdatennachricht aufgenommen, die übertragen wird. Am bevorzugtesten wird die verschlüsselte normale Kurzdatennachricht oder der verschlüsselte normale Kurzdatennachrichtenteil dann (vorzugsweise zusammen mit jeglichen verbleibenden normalen Kurzdatennachrichtenheadern usw., die sich in einer normalen Kurzdatennachricht befinden würden, jedoch nicht im verschlüsselten Kurzdatennachrichtenteil vorhanden sind) in eine Standard-Kurzdatennachrichtenstruktur gepackt, so dass sie im Wesentlichen in einem anscheinend normalen Kurzdatennachrichten-Wrapper angeordnet wird, wobei diese Struktur (der Wrapper) jedoch den Hinweis aufweist, dass die enthaltene Nachricht eine verschlüsselte Kurzdatennachricht ist. Nach dem Sehen dieses Hinweises entschlüsselt der Empfänger dann die Originalkurzdatennachricht und verarbeitet sie anschließend als eine normale Kurzdatennachricht.
Wenn die Nachricht verschlüsselt wird, wäre es typischerweise auch erforderlich, weitere Verschlüsselungsinformationen, beispielsweise in Form eines Verschlüsselungsheaders, aufzunehmen, um zu ermöglichen, dass der Empfänger die Nachricht entschlüsselt. Diese Verschlüsselungsinformationen oder dieser Verschlüsselungsheader folgt vorzugsweise dem Verschlüsselungshinweis und befindet sich vorzugsweise an einer vorgegebenen oder zuvor festgelegten Stelle in der Nachricht, um die schnelle Identifikation durch den Empfänger zu ermöglichen. Wenn dies geeignet ist, wird er vorzugsweise außerhalb der verschlüsselten Kurzdatennachricht in geeigneter Weise in dem gesamten Kurzdatennachrichten-"Wrapper" angeordnet. Er wird vorzugsweise gegen Anfang der Nachricht angeordnet, um Nachrichten mit verschiedenen Längen zu ermöglichen, wie vorstehend erörtert wurde.
TETRA stellt eine Anzahl verschiedener Kurzdatennachrichtentypen bereit: kurze "Statusnachrichten", Freiformat-SDS-Nachrichten und so genannte Typ-4-SDS-Nachrichten. Die Anmelder nehmen an, dass es sehr wahrscheinlich wünschenswert ist, Typ-4-SDS-Nachrichten für eine Verschlüsselung von Ende zu Ende zu verwenden, weil sie mehr benutzerdefinierte Daten und daher eine längere Benutzernachricht enthalten können und sie daher eine größere Kapazität zum Übertragen der Benutzerdaten zusammen mit den erforderlichen Verschlüsselungssynchronisationsinformationen in der Art des Verschlüsselungssynchronisationsvektors usw., die erforderlich sein können, um das Entschlüsseln der Nachricht zu ermöglichen, aufweisen.
TETRA-Typ-4-SDS-Nachrichten sind in ETSI ETS 300 392-2, Klausel 29, definiert. 1 zeigt das Format einer Anordnung einer Typ-4-SDS-Nachricht. Die Nachricht 1 beinhaltet einen führenden "SDS-Protokollkennungsteil" oder ein führendes "SDS-Protokollkennungsfeld" 2, worin die ersten 8 Bits der Nachricht enthalten sind. Die Protokollkennung ermöglicht es der SDS-Anwendung im Funkendgerät, den restlichen Inhalt der SDS-Nachricht zur vorgesehenen Anwendung zu übermitteln, und gestattet eine korrekte Decodierung der Nachricht. (Mögliche Anwendungen umfassen eine Schlüsselverwaltung einer Verschlüsselung von Ende zu Ende (OTAR – Über-die-Luft-Umverschlüsselung), eine Textnachrichtenübermittlung, das drahtlose Datagrammprotokoll WAP, das drahtlose Steuernachrichtenprotokoll WCMP, den gesteuerten TETRA-Direktmodus, die PIN-Authentifizierung und GPS-Positionsinformationen (siehe beispielsweise ETSI ETS 300-392-2, 29.4.3.8)). Die Benutzernachricht 3 folgt der Protokollkennung 2.
Typ-4-SDS-Nachrichten können auch eine zusätzliche Protokollschicht oder -einrichtung verwenden, die als Short Data Service Transport Layer (SDS-TL)-Datenübertragungsdienst bekannt ist (siehe beispielsweise ETSI ETS 300 392-2; 29, 29.4.1, 29.4.2 und Anhang J). Diese zusätzliche Protokollschicht erweitert das Short Data Service-Protokoll und verbessert die Zuverlässigkeit des Nachrichtentransports usw. durch Bereitstellen von Protokollmechanismen beispielsweise für eine Bestätigung von Ende zu Ende und Speicherungs- und Weiterleitungsfunktionen. Sie gewährleistet auch, dass Anwendungen, bei denen dieser Dienst verwendet wird, die Benutzerdaten in der gleichen Weise interpretieren.
Wenn das SDS-TL-Protokoll verwendet wird, beinhaltet die Kurzdatennachricht zusätzliche Headerinformationen in Form eines SDS-TL-Headers. 2 zeigt eine solche Nachricht 5. Der SDS-TL-Header 4 ist hinter der Protokollkennung 2, jedoch vor der Benutzernachricht 3 eingefügt. Bei einer Typ-4-SDS-Nachricht gibt das erste Bit der Protokollkennung 2 an, ob das SDS-TL-Protokoll verwendet wird (siehe beispielsweise ETSI ETS 300 392-2; 29.4.1 und Anhang J), und daher beispielsweise, ob ein TL-Header in der Nachricht enthalten ist.
Demgemäß könnte bei der Anwendung der vorliegenden Erfindung auf eine TETRA-Typ-4-SDS-Nachricht beispielsweise der Verschlüsselungshinweis der Protokollkennung folgen und dem SDS-TL-Header, falls vorhanden, vorhergehen oder folgen. Die verschlüsselte Nachricht würde dann folgen und, wenn verschlüsselt, das Standard-Typ-4-SDS-Format aufweisen.
Wenn das TETRA-SDS-TL-Protokoll verwendet wird, kann der SDS-TL-Header, falls gewünscht, verschlüsselt werden. Die Anmelder nehmen jedoch an, dass es im Allgemeinen bevorzugt wäre, den TL-Header nicht zu verschlüsseln, weil es nützlich sein kann, dass die Informationen, die er enthält, noch von Einheiten des Systems, beispielsweise der Systeminfrastruktur oder einer anderen Mobileinheit, welche nicht der vorgesehene Empfänger der Nachricht sind (und daher nicht die ganze Nachricht entschlüsseln können), lesbar sind. Beispielsweise kann der TL-Header Informationen enthalten, die von der Systeminfrastruktur verwendet werden können, um festzustellen, ob und wie lange die Nachricht gespeichert oder weitergeleitet werden sollte. Es wäre nützlich, wenn die Infrastruktur noch in der Lage wäre, diese Informationen zu lesen, selbst wenn sie nicht die ganze Nachricht entschlüsseln kann und nicht dafür vorgesehen ist. Falls der TL-Header jedoch verschlüsselt ist, ist die Infrastruktur nicht in der Lage, ihn zu decodieren.
Es kann auch bevorzugt sein, dass eine Mobilstation in der Lage ist, den TL-Header selbst dann zu lesen, wenn sie nicht in der Lage ist, den Rest der Nachricht zu entschlüsseln. Dies liegt daran, dass der TL-Header beispielsweise angeben kann, ob die Mobilstation mitteilen sollte, ob der Empfang der Nachricht erfolgreich war oder fehlgeschlagen ist.
Tatsächlich gibt gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung der vorgesehene Empfänger der Nachricht (beispielsweise die Mobilstation des Empfängers) eine Fehlermeldung, wie "Verschlüsselung nicht unterstützt", zurück, falls er die Nachricht nicht entschlüsseln kann. Dies könnte in einem TETRA-System unter Verwendung einer kurzen Mitteilung geschehen (siehe beispielsweise ETSI ETS 300-392-2, 29.4.3.10), die im TETRA SDS-SHORT REPORT PDU (ETSI ETS 300-392-2; 29.4.2.3) verwendet wird, oder unter Verwendung eines neuen Werts geschehen, der "nicht in der Lage, Nachricht zu entschlüsseln" im "Übermittlungsstatus"-Parameter (ETSI ETS 300-392-2; 29.4.3.2), der im SDS-REPORT PDU (ETSI ETS 300-392-2, 29.4.2.2) verwendet wird, bedeutet.
Bei einer TETRA-SDS-TL-Protokollanordnung könnte, ob der TL-Header zu verschlüsseln ist oder nicht, beispielsweise vorbestimmt sein oder bei der Verwendung vorangeordnet werden (beispielsweise dem Empfänger in einer früheren Nachricht angegeben werden) oder durch den Verschlüsselungshinweis angegeben werden (beispielsweise dadurch, dass er einen bestimmten Wert annimmt) oder dies könnte innerhalb des in der Kurzdatennachricht enthaltenen Verschlüsselungsheaders (falls vorhanden) angegeben werden.
Wenngleich die vorstehend beschriebenen Sequenzen von Verschlüsselungshinweisen, Headern und Benutzernachrichten bevorzugt und zweckmäßig sind, ist die Reihenfolge in der Praxis unwichtig, solange die relevanten Parteien die zu verwendende und zu erwartende Reihenfolge kennen.
Der Verschlüsselungshinweis gemäß der vorliegenden Erfindung wird unter Verwendung eines bestimmten TETRA- Protokollkennungswerts oder bestimmter TETRA-Protokollkennungswerte als Verschlüsselungshinweis gegeben. Dies bedeutet, dass der Verschlüsselungshinweis gegeben wird, indem ein Wert eines existierenden Teils oder Felds der TETRA-Kurzdatennachrichtenstruktur auf einen bestimmten Wert oder bestimmte Werte gesetzt wird. (Wie auf dem Fachgebiet bekannt ist, beinhalten die TETRA-Kurzdatennachrichtenanordnungen Header oder ähnliche Teile oder Felder, die "Strukturdaten", d.h. Daten, die das System benötigt, um zu arbeiten, jedoch ansonsten keine Benutzerinformationen korrekt übertragen, statt korrekte Benutzerinformationen oder erwünschte Daten, wozu die "Protokollkennung" (PID) gehört, enthalten. Diese "Strukturdatenelemente" werden normalerweise auf bestimmte Werte gesetzt, um bestimmte Informationen zu übermitteln, die ermöglichen, dass das System arbeitet, sie sind jedoch spärliche, unbenutzte Werte, auf die diese Teile, Header, Felder usw. gesetzt werden können, welchen keine bestimmten Bedeutungen zugewiesen wurden. Die vorliegende Erfindung verwendet zuvor undefinierte PID-Werte, die die Bedeutungen "verschlüsselte Nachricht" oder "unverschlüsselte Nachricht" usw. aufweisen, wodurch der Verschlüsselungshinweis gegeben wird.)
Durch Aufnehmen des Verschlüsselungshinweises in die existierende Kurzdatennachrichtenstruktur des TETRA-Kommunikationssystems auf diese Weise, statt durch Hinzufügen zusätzlicher Markierungsbits zur Nachrichtenstruktur, wird vermieden, dass eine zusätzliche Verschlüsselungsmarkierung zur Kurzdatennachricht hinzugefügt werden muss. Hierdurch wird beispielsweise ein Nachteil vermieden, der auftritt, wenn einfach eine zusätzliche Verschlüsselungshinweismarkierung zum existierenden Kurzdatennachrichtenformat, beispielsweise als ein zusätzliches Bit oder als zusätzliche Bits zu Beginn der Nachricht hinzugefügt wird (die dann ansonsten die normale Kurzdatennachrichtenstruktur des Kommunikationssystems aufweisen könnte, abgesehen davon, dass sie verschlüsselt ist und möglicherweise den Verschlüsselungsheader aufweist), wobei der Nachteil darin besteht, dass das existierende Kurzdatennachrichtenformat für das TETRA-Kommunikationssystem das Hinzufügen einer Markierung auf diese Weise nicht unterstützt, weil es nicht die Kapazität für das zusätzliche Bit oder für die zusätzlichen Bits einer Verschlüsselungsmarkierung aufweist. Dies ist beispielsweise bei TETRA-Typ-4-SDS-Nachrichten der Fall, weil die Fähigkeit zum Hinzufügen einer zusätzlichen Markierung auf diese Weise nicht aufgenommen wurde, als der Typ-4-SDS-Dienst definiert wurde. Demgemäß ist das Hinzufügen einer Markierung zu einer Standard-Typ-4-SDS-Nachricht im TETRA-System nicht mehr so einfach zu implementieren, weil dies eine gewisse Neudefinition des Typ-4-SDS-Dienstes erfordern würde.
Bei einem TETRA-System, bei dem Typ-4-SDS-Nachrichten verwendet werden, wird die Erfindung bei einer Anordnung vorzugsweise so implementiert, dass der Verschlüsselungshinweis aus zwei auf die Verschlüsselung hinweisenden Protokollkennungswerten besteht, wobei einer die Bedeutung "verschlüsselte SDS-Nachricht" aufweist und der andere die Bedeutung "verschlüsselte SDS-TL-Nachricht" aufweist, um zu ermöglichen, dass die entschlüsselnde Empfängerstation das Vorhandensein des TL-Headers feststellt, wenn das SDS-TL-Protokoll verwendet wird.
Wenn bei einer solchen Anordnung eine dieser Protokoll kennungen verwendet wird, folgt ihr vorzugsweise der Verschlüsselungsheader (falls vorhanden), und es wurde dann eine verschlüsselte Version der Originalnachricht vor der Verschlüsselung hinzugefügt, d.h. eine verschlüsselte Nachricht, die die wahre Protokollkennung, den SDS-TL-Header (falls vorhanden) und die Benutzernachricht enthält. Mit anderen Worten wird die Originalnachricht im Wesentlichen wie gewöhnlich formatiert und dann verschlüsselt, und es wird dann die verschlüsselte Nachricht auf das gewöhnliche SDS-Nachrichtenformat abgebildet, wobei die so gebildete Nachricht jedoch einen speziellen Protokollkennungswert aufweist, der sie als eine verschlüsselte SDS-Nachricht enthaltend identifiziert.
Wie vorstehend erörtert wurde, kann es, wenngleich es im Allgemeinen bevorzugt sein kann, den TL-Header unverschlüsselt zu halten, unter manchen Umständen erwünscht sein, ihn zu verschlüsseln. Es ist dem Empfänger daher vorzugsweise möglich festzustellen, ob der TL-Header verschlüsselt ist.
Dies könnte beispielsweise erreicht werden, indem drei verschiedene Protokollkennungswerte aufgenommen werden, welche "verschlüsselte SDS-Nachricht", "verschlüsselte SDS-TL-Nachricht mit unverschlüsseltem TL-Header" und "verschlüsselte SDS-TL-Nachricht mit verschlüsseltem TL-Header" darstellen. Eine Infrastruktur, die beispielsweise die Protokollkennung "verschlüsselte SDS-TL-Nachricht mit unverschlüsseltem TL-Header" sieht, wäre dann in der Lage, nach dem TL-Header zu suchen und die Nachricht in der gleichen Weise wie jede andere SDS-TL-Nachricht zu behandeln.
Die Anmelder haben jedoch erkannt, dass in einem TETRA-System eine Protokollkennung, deren höchstwertiges Bit auf "0" gesetzt ist, die Systeminfrastruktur und Mobilstationen darauf hinweist, dass sie nicht versuchen sollten, eine TL-Header zu lesen, während eine "1" im höchstwertigen Bit angibt, dass nach einem TL-Header gesucht werden sollte (siehe beispielsweise ETSI ET3 300-392-2; Anhang J). Weil demgemäß ein TL-Header nicht in einer verschlüsselten SDS-Nachricht und einer verschlüsselten SDS-TL-Nachricht mit einem verschlüsselten TL-Header gelesen werden sollte, kann eine Protokollkennung, deren höchstwertiges Bit auf "0" gesetzt ist, verwendet werden, um das System auf solche Nachrichten hinzuweisen und es ihm zu ermöglichen, sie richtig zu verarbeiten. Wenn nach dem TL-Header in einer verschlüsselten SDS-TL-Nachricht mit einem unverschlüsselten TL-Header gesucht werden sollte, kann eine Protokollkennung, deren höchstwertiges Bit auf "1" gesetzt ist, verwendet werden, um das System auf solche Nachrichten hinzuweisen und es dem System zu ermöglichen, sie richtig zu verarbeiten. Auf diese Weise sind nur zwei Protokollkennungswerte erforderlich, um auf die vorstehend erwähnten drei möglichen Nachrichtenzustände angemessen hinzuweisen.
Demgemäß werden gemäß einer besonders bevorzugten Ausführungsform zwei und vorzugsweise nur zwei Protokollkennungswerte verwendet, um auf die Verschlüsselung hinzuweisen, wobei bei dem einen das erste (höchstwertige) Bit auf "0" (Null) gesetzt ist, wobei es für verschlüsselte SDS-Nachrichten und verschlüsselte SDS-TL-Nachrichten mit einem verschlüsselten TL-Header verwendet wird, und bei dem anderen das erste (höchstwertige) Bit auf "1" (Eins) gesetzt ist, wobei es für verschlüsselte SDS-TL-Nachrichten mit einem unverschlüsselten TL-Header verwendet wird.
Demgemäß wird jede SDS-TL-Nachricht, in der der TL-Header unverschlüsselt ist, vorzugsweise mit einer Protokollkennung gesendet, deren höchstwertiges Bit auf "1" gesetzt ist, so dass die Empfänger wissen, dass sie nach dem TL-Header suchen sollen. Eine SDS-TL-Nachricht, bei der der TL-Header verschlüsselt ist, wird vorzugsweise mit einem Protokollkennungswert gesendet, bei dem eine "0" das höchstwertige Bit ist (wie es bei einer verschlüsselten SDS-Nachricht der Fall wäre), wodurch im Wesentlichen ein Empfänger angewiesen wird, nicht nach einem TL-Header zu suchen. In diesem Fall wird die Tatsache, dass die Nachricht tatsächlich eine SDS-TL-Nachricht mit einem verschlüsselten TL-Header ist, verständlich, wenn die Nachricht entschlüsselt wird, weil die Protokollkennung der ursprünglichen Nachricht dann sichtbar wird. Die Nachricht kann dann decodiert, verwaltet, bestätigt und verworfen werden, wie es bei jeder normalen unverschlüsselten Typ-4-SDS-Nachricht der Fall ist.
Wenngleich es bevorzugt ist, zwei oder drei und vorzugsweise nur zwei Protokollkennungswerte bei dieser Anordnung zu verwenden, wie vorstehend erörtert wurde, könnten mehr solche Werte verwendet werden, falls es beispielsweise erwünscht ist, verschiedene Protokollkennungswerte für verschiedene Typen verschlüsselter Nachrichten zu verwenden. Demgemäß können Protokollkennungswerte (außer denen, die bereits für einen anderen Zweck definiert wurden) vordefiniert werden, um beispielsweise den Typ der folgenden verschlüsselten Nachricht, beispielsweise, ob es sich um eine verschlüsselte Textnachricht, eine verschlüsselte GPS-Nachricht usw. handelt, anzugeben. Die höchstwertigen Bits dieser Protokollkennungswerte sind vorzugsweise auf "0" oder "1" gesetzt, um nach Bedarf das Vorhandensein eines unverschlüsselten TL-Headers anzugeben, wie vorstehend erörtert wurde.
Demgemäß kann der Verschlüsselungshinweis gemäß der vorliegenden Erfindung, allgemeiner gesagt, auch verwendet werden, um den Typ der verschlüsselten Nachricht anzugeben, falls dies erwünscht ist, beispielsweise indem ihr, abhängig vom Typ der verschlüsselten Nachricht, verschiedene Werte gegeben werden.
Kurzdatennachrichten gemäß der vorliegenden Erfindung können nach Wunsch zusammengestellt und übertragen werden. Gemäß einer besonders bevorzugten Ausführungsform beinhaltet, wie vorstehend erwähnt wurde, diese Übertragung die grundlegende Benutzernachricht (beispielsweise die GPS-Nachricht), die gebildet wird und dann in das relevante Kurzdatennachrichtenformat (beispielsweise das TETRA-SDS- oder -SDS-TL-Format) gepackt wird. Die so formatierte Nachricht wird dann verschlüsselt.
Auf die Notwendigkeit der Verschlüsselung kann beispielsweise vom Benutzer hingewiesen werden. Alternativ oder zusätzlich könnte vorgegeben werden, dass bestimmte Nachrichten verschlüsselt werden sollten oder verschlüsselt werden sollten, wenn bestimmte vorgegebene Bedingungen erfüllt sind. Beispielsweise ist es gewöhnlich wünschenswert, dass Positionsinformationsnachrichten besonders verschlüsselt werden. Zusätzlich oder alternativ könnte das Ziel der Nachricht verwendet werden, um eine Verschlüsselung von Ende zu Ende auszulösen und/oder um zumindest den geeigneten Verschlüsselungscode auszuwählen.
(Es ist jedoch bevorzugt, dass die Anwendung die Verwendung der Verschlüsselung bestimmt.) Falls ein Verschlüsselungscode für ein bestimmtes Ziel nicht verfügbar ist, wird die Nachricht vorzugsweise blockiert.
Die so verschlüsselte Nachricht wird dann weiter zusammen mit, falls geeignet, einem kryptographischen Header, der die für die Entschlüsselung zu verwendenden Parameter angibt, in das relevante Kurzdatennachrichtenformat gepackt, wobei jedoch der Verschlüsselungshinweis darin aufgenommen wird, indem eine Protokollkennung innerhalb der gebildeten Kurzdatennachricht auf einen bestimmten Wert gesetzt wird. Die so zusammengestellte Kurzdatennachricht kann dann zur Übertragung über die Funkschnittstelle weitergeleitet werden.
Das Empfangen und Entschlüsseln einer eingehenden Kurzdatennachricht, die eine verschlüsselte Nachricht enthält, würde dem umgekehrten Prozess folgen.
Demgemäß weist das Verfahren gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung die folgenden Schritte auf:
Bilden der Nachricht, die verschlüsselt werden soll,
Bereitstellen eines Protokollkennungswerts für die zu verschlüsselnde Nachricht,
Verschlüsseln der zu verschlüsselnden Nachricht und deren Protokollkennungswerts,
Packen der verschlüsselten Nachricht und des verschlüsselten Protokollkennungswertes in ein TETRA-SDS-Nachrichtenformat,
Versehen der so gebildeten SDS-Nachricht mit einem weiteren Protokollkennungswert, der die SDS-Nachricht als eine eine verschlüsselte Nachricht enthaltende Nachricht identifiziert, und
Übertragen der so konstruierten Kurzdatennachricht.
Ähnlich weist gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung die Vorrichtung auf:
Mittel zum Bilden der zu verschlüsselnden Nachricht,
Mittel zum Bereitstellen eines Protokollkennungswertes für die zu verschlüsselnde Nachricht,
Mittel zum Verschlüsseln der zu verschlüsselnden Nachricht und deren Protokollkennungswerts,
Mittel zum Packen der verschlüsselten Nachricht und des verschlüsselten Protokollkennungswertes in einem TETRA-SDS-Nachrichtenformat,
Mittel zum Versehen der so gebildeten SDS-Nachricht mit einem weiteren Protokollkennungswert, der die SDS-Nachricht als eine eine verschlüsselte Nachricht enthaltende Nachricht identifiziert, und
Mittel zum Übertragen der so konstruierten Kurzdatennachricht.
Diese Ausführungsformen der vorliegenden Erfindung können eines oder mehrere der vorstehend erörterten bevorzugten Merkmale aufweisen. Beispielsweise ist das Standard-Kurzdatennachrichtenformat, in das die Originalnachricht gepackt ist, entweder das SDS- oder das SDS-TL-Format (wobei der TL-Header in diesem Fall nach Wunsch verschlüsselt oder unverschlüsselt sein könnte).
Gemäß einer bevorzugten Ausführungsform wird die Original-Kurzdatennachricht mit einer temporären Kennungsmarke markiert, bevor sie verschlüsselt wird, wobei die Marke nicht durch den Verschlüsselungsprozess geändert wird, so dass die Vorrichtung die verschlüsselte Kurzdatennachricht identifizieren kann und sie beispielsweise zum richtigen Ziel senden kann.
Gemäß einem dritten Aspekt der vorliegenden Erfindung ist eine Kurzdatennachricht für ein TETRA-Mobilkommunikationssystem vorgesehen, aufweisend: eine verschlüsselte Nachricht und einen Hinweis, dass die Kurzdatennachricht eine verschlüsselte Nachricht umfasst, wobei der Verschlüsselungshinweis einen bestimmten Protokollkennungswert umfasst und die Kurzdatennachricht die auf die Verschlüsselung hinweisende Protokollkennung aufweist, der ein verschlüsselter Teil der Kurzdatennachricht folgt, welcher eine Protokollkennung für die Nachricht, die verschlüsselt ist, und die verschlüsselte Nachricht enthält.
Dieser Aspekt der Erfindung kann eines oder mehrere der vorstehend erörterten bevorzugten Merkmale einschließen.
Die Verfahren gemäß der vorliegenden Erfindung können zumindest teilweise unter Verwendung von Software, beispielsweise von Computerprogrammen, implementiert werden. Es wird daher verständlich sein, dass die vorliegende Erfindung bei Betrachtung anderer Aspekte Computersoftware, die speziell dafür eingerichtet ist, die vorstehend beschriebenen Verfahren auszuführen, wenn sie auf Datenverarbeitungseinrichtungen installiert ist, und ein Computerprogrammelement, das Computersoftware-Codeabschnitte zum Ausführen der vorstehend beschriebenen Verfahren aufweist, wenn das Programmelement auf Datenverarbeitungseinrichtungen ausgeführt wird, vorsieht. Die Erfindung betrifft auch einen Computersoftwareträger mit Software, die, wenn sie zum Betreiben eines Funksystems oder einer Einheit mit einem Digitalcomputer verwendet wird, in Zusammenhang mit dem Computer das System oder die Einheit veranlasst, die Schritte des erfindungsgemäßen Verfahrens auszuführen. Ein solcher Computersoftwareträger könnte ein physikalisches Speichermedium in der Art eines ROM-Chips, einer CD-ROM oder einer Platte sein, oder er könnte ein Signal in der Art eines elektronischen Signals über Leitungen, eines optischen Signals oder eines Funksignals, beispielsweise zu einem Satelliten oder dergleichen, sein.
Es sei weiter bemerkt, dass nicht alle Schritte des erfindungsgemäßen Verfahrens durch Computersoftware ausgeführt zu werden brauchen.
Eine Anzahl bevorzugter Ausführungsformen der vorliegenden Erfindung wird nun nur als Beispiel und mit Bezug auf die anliegende Zeichnung beschrieben, worin:
1 die Struktur einer TETRA-Typ-4-SDS-Nachricht zeigt,
2 die Struktur einer TETRA-Typ-4-SDS-TL-Nachricht zeigt,
3 das Senden einer verschlüsselten Typ-4-SDS-Nachricht unter Verwendung einer speziellen Protokollkennung gemäß der vorliegenden Erfindung zeigt,
4 das Senden einer verschlüsselten Typ-4-SDS-TL-Nachricht unter Verwendung einer speziellen Protokollkennung gemäß einer Ausführungsform der vorliegenden Erfindung zeigt, worin der TL-Header verschlüsselt ist,
5 das Senden einer verschlüsselten Typ-4-SDS-TL-Nachricht unter Verwendung einer speziellen Protokollkennung gemäß einer Ausführungsform der vorliegenden Erfindung zeigt, worin der TL-Header nicht verschlüsselt ist, und
6 ein schematisches Diagramm ist, worin dargestellt ist, wie eine verschlüsselte Nachricht in einem Sender gemäß einer Ausführungsform der vorliegenden Erfindung behandelt wird.
Die 3, 4 und 5 zeigen eine Ausführungsform der vorliegenden Erfindung zum Übertragen verschlüsselter TETRA-Typ-4-SDS-Nachrichten, welche "Protokollkennungswerte" mit den Bedeutungen "verschlüsselte SDS-Nachricht" und "verschlüsselte SDS-TL-Nachricht" verwenden, um auf das Vorhandensein einer verschlüsselten Nachricht hinzuweisen. Bei dieser Anordnung ist es nicht erforderlich, eine Verschlüsselungsmarkierung zum Format normaler TETRA-SDS-Nachrichten hinzuzufügen.
Die in den 3, 4 und 5 dargestellten SDS-Nachrichten 60, 70, 77 umfassen jeweils die spezielle Protokollkennung 61, 71, 76, welche angibt, dass die SDS-Nachricht eine verschlüsselte Benutzernachricht aufweist (in diesem Fall sind sowohl die wahre Protokollkennung als auch die Benutzernachricht verschlüsselt), gefolgt von einem Verschlüsselungsheader 62, 73, der typischerweise aus einem Verschlüsselungsalgorithmusindikator, einer Schlüsselkennung, einem Anfangswert (IV) für die Synchronisation und wahlweise einem Zeitstempel und einer Prüfsumme bestehen könnte. Dieser Verschlüsselungsheader könnte eine Länge von beispielsweise 8 bis 16 Oktetts aufweisen. Der Rest jeder Nachricht folgt der normalen Typ-4-SDS-Nachrichtenstruktur, ist jedoch verschlüsselt. Sie beinhalten demgemäß eine verschlüsselte Protokollkennung 63, 74 und die verschlüsselte Benutzernachricht 64, 75.
Bei diesen Ausführungsformen folgt der Header unmittelbar der verschlüsselten SDS-Nachrichtenprotokollkennung, und das Format gleicht anschließend demjenigen für unverschlüsselte Nachrichten. (Alternativ könnte der verschlüsselten SDS-TL-Nachrichtenprotokollkennung der unverschlüsselte TL-Header folgen, so dass die Infrastruktur die Nachricht beispielsweise insbesondere wie jede andere SDS-TL-Nachricht behandeln kann.)
3 zeigt die Struktur einer SDS-Nachricht 60 zum Senden einer verschlüsselten Typ-4-SDS-Nachricht gemäß dieser Ausführungsform. Die Nachricht umfasst eine führende spezielle Protokollkennung 61, welche "verschlüsselte SDS-Nachricht" angibt, gefolgt vom Verschlüsselungsheader 62. Es folgt dann der restliche verschlüsselte Teil 65 der Nachricht, der die normale "wahre" SDS-Protokollkennung 63 (die nun verschlüsselt ist) und die verschlüsselte Benutzernachricht 64 aufweist. (Demgemäß ist ersichtlich, dass die Teile 63 und 64 im Wesentlichen eine verschlüsselte normale SDS-Nachricht sind, die dann zusammen mit dem Verschlüsselungsheader 62 in einen SDS-"Wrapper" mit der speziellen "Verschlüsselte-SDS-Nachricht"-Protokollkennung 61 neu gepackt wird.)
4 zeigt die Struktur einer SDS-Nachricht 70 zum Senden einer verschlüsselten Typ-4-SDS-TL-Nachricht gemäß dieser Ausführungsform, wobei der TL-Header verschlüsselt ist. In diesem Fall geht die spezielle Protokollkennung 71 verschlüsselte SDS-Nachricht" der Nachricht 70 voraus, und ihr folgt ein Verschlüsselungsheader 62. Der restliche Teil 66 der Nachricht ist verschlüsselt und folgt demselben Format wie eine normale SDS-Nachricht und beinhaltet daher die wahre Protokollkennung 74 (die verschlüsselt ist), den TL-Header 72 (der verschlüsselt ist) und die verschlüsselte Benutzernachricht 75.
5 zeigt die Struktur einer SDS-Nachricht 77 zum Senden einer verschlüsselten Typ-4-SDS-TL-Nachricht, die gemäß dieser Ausführungsform angeordnet ist, wobei der TL-Header jedoch nicht verschlüsselt ist. Die Nachricht 77 umfasst die spezielle Protokollkennung 76, welche "verschlüsselte SDS-TL-Nachricht" angibt, gefolgt vom unverschlüsselten TL-Header 78 (der vorzugsweise daneben angeordnet ist, so dass die Infrastruktur die Nachricht beispielsweise wie jede andere SDS-TL-Nachricht behandeln kann (wenngleich in der Praxis die tatsächliche Sequenz von Headern und Indikatoren unwichtig ist, solange alle Parteien die Sequenz vorab kennen)), und dann den Verschlüsselungsheader 73. Der restliche Teil 67 der Nach richt ist dann verschlüsselt und beinhaltet die originale, wahre Protokollkennung 74 und die Benutzernachricht 75. Die Verwendung eines unverschlüsselten TL-Headers kann beispielsweise zuvor eingerichtet werden, oder diese Tatsache kann, wenn der TL-Header selektiv unverschlüsselt sein kann, geeignet in der Verschlüsselungsmarkierung, beispielsweise durch Definieren eines dritten Werts dafür, angegeben werden.
6 zeigt schematisch, wie verschlüsselte Kurzdatennachrichten gemäß der vorliegenden Erfindung durch eine TETRA-Funkeinheit 100 übermittelt werden können. Die Einheit beinhaltet eine GPS-(globales Positionierungssystem)-Einheit 105, andere Module 104, 106, die andere Anwendungen, wie Textnachrichtenübermittlungen oder ein gesteuerter Direktmodus sein können, welche möglicherweise von Zeit zu Zeit empfangene verschlüsselte Kurzdatennachrichten senden möchten, eine Kurzdatendienst-(SDS)-Anwendungseinheit 102, eine Verschlüsselungseinheit 103 und die normalen unteren TETRA-Protokollschichten 101, welche die Nachricht zur Übertragung über die Funkschnittstelle vorbereiten.
6 zeigt die Situation, in der es erwünscht ist, eine GPS-Kurzdatennachricht zu senden, die verschlüsselt ist. Die grundlegende GPS-Nachricht wird von der GPS-Einheit 105 zur SDS-Anwendungseinheit 102 gesendet. Die SDS-Anwendungseinheit verpackt die Nachricht ins Standard-SDS- oder SDS-TL-Format (nach Bedarf). Die SDS-Anwendungseinheit 102 bestimmt auch, ob die Nachricht verschlüsselt werden sollte, möglicherweise durch Annehmen eines Befehls von der GPS-Einheit 105 oder beispielsweise durch Lesen einiger vorgespeicherter Informationen, die es notwendig machen, dass Nachrichten von der GPS-Einheit verschlüsselt werden.
Falls die Nachricht zu verschlüsseln ist, sendet die SDS-Anwendungseinheit 102 die SDS-Nachricht zur Verschlüsselungseinheit 103. Die Verschlüsselungseinheit 103 verschlüsselt die gesamte SDS- oder SDS-TL-Nachricht und spannt den Verschlüsselungsheader vor, der die für die Entschlüsselung zu verwendenden Parameter angibt. Die Verschlüsselungseinheit 103 führt die Nachricht dann zur SDS-Anwendungseinheit 102 zurück. Die SDS-Anwendungseinheit 102 spannt dann nach Bedarf den Protokollkennungswert "verschlüsselte SDS-Nachricht" oder "verschlüsselte SDS-TL-Nachricht" usw. vor und übergibt die gesamte Nachricht zur Übertragung über die Funkschnittstelle an die unteren Protokollschichten 101. (Bei einer alternativen Anordnung könnte die Verschlüsselungseinheit 103 den "verschlüsselte Nachricht"-Hinweis vorspannen und die Nachricht dann an die SDS-Anwendungseinheit 102 weiterleiten. Dies kann bevorzugt sein, weil dadurch das Risiko verringert wird, dass unverschlüsseltes Material von der SDS-Anwendungseinheit unbeabsichtigt mit verschlüsseltem Material gemischt wird.)
Falls gewünscht, kann die SDS-Anwendungseinheit 102 die SDS-Nachricht mit einer temporären Kennungsmarke markieren, bevor sie sie zur Verschlüsselungseinheit 103 weiterleitet. Die Verschlüsselungseinheit sollte dann diese Marke unverändert lassen, so dass die SDS-Anwendungseinheit 102 die verschlüsselte SDS identifizieren kann und sie zum richtigen Ziel senden kann (wie beispielsweise von der einleitenden GPS-Anwendungseinheit 105 angefordert).
Der Empfang und die Entschlüsselung einer eingehenden SDS-Nachricht folgen dem umgekehrten Prozess, abgesehen davon, dass die SDS-Anwendungseinheit 102, wenn die unverschlüsselte SDS-Nachricht von der Verschlüsselungseinheit 103 an die SDS-Anwendungseinheit 102 weitergeleitet wird, in der Lage ist, die wahre Protokollkennung innerhalb der Nachricht zu lesen und dadurch die SDS-Nachricht zu ihrer Zielanwendung weiterzuleiten (beispielsweise einer Textanzeige-Anwendungseinheit oder, im Fall von Positionsinformationen, einer Anzeigeeinheit, die die Orte mobiler Einheiten auf einer Karte auf einem Bildschirm anzeigt).
Es ist anhand des vorstehend Erwähnten ersichtlich, dass die vorliegende Erfindung zumindest gemäß ihren bevorzugten Ausführungsformen einen Weg zum Verschlüsseln von TETRA-SDS-Nachrichten von einem Ende zum anderen bereitstellt, der auf den bestehenden TETRA-SDS-Mechanismus aufbaut, indem eine Verschlüsselung von einem Ende zum anderen zu der bestehenden SDS-Typ-4-Nachrichtenstruktur hinzugefügt wird.

Claims

Verfahren zum Übertragen einer Kurzdatennachricht (englisch: short data message) in einem TETRA-Mobilkommunikationssystem, bei dem, wenn die Kurzdatennachricht eine verschlüsselte Nachricht umfasst, ein Hinweis auf diese Tatsache in die Kurzdatennachricht aufgenommen wird, wobei das Verfahren dadurch gekennzeichnet ist, dass es ferner umfasst: Verwenden bestimmter Protokollkennungswerte als Verschlüsselungshinweis und Bilden der Kurzdatennachricht (60), so dass sie die auf die Verschlüsselung hinweisende Protokollkennung (61), gefolgt von einem verschlüsselten Teil (65) der Kurzdatennachricht mit einer Protokollkennung (63) für die Nachricht, die verschlüsselt ist, und der verschlüsselten Nachricht (64), aufweist.
Verfahren nach Anspruch 1, wobei der Verschlüsselungshinweis der verschlüsselten Nachricht vorangeht.
Verfahren nach Anspruch 1 oder 2, wobei der Verschlüsselungshinweis auch zum Anzeigen der Art der verschlüsselten Nachricht verwendet wird.
Verfahren nach Anspruch 1, 2 oder 3, wobei die in einer verschlüsselten Form zu versendende Nachricht eine Textnachricht, eine Statusnachricht, oder eine Positionsaktualisierungsnachricht umfasst.
Verfahren nach einem der Ansprüche 1 bis 4, wobei die Kurzdatennachricht, die übertragen wird, in einer Standard kurzdatennachrichtenstruktur des TETRA-Kommunikationssystems verpackt wird.
Verfahren nach einem der Ansprüche 1 bis 5, wobei die Kurzdatennachricht als eine Typ-4-SDS-Nachricht versendet wird.
Verfahren nach Anspruch 6, wobei die Nachricht als eine Typ-4-SDS-Nachricht unter Verwendung SDS-TL versendet wird und der TL-Header (78) unverschlüsselt versendet wird.
Verfahren nach einem der Ansprüche 1 bis 7, wobei die übertragene Kurzdatennachricht Verschlüsselungsinformationen (62) umfasst, um den Empfänger zu unterstützen, die Nachricht zu entschlüsseln.
Verfahren nach Anspruch 8, wobei die Verschlüsselungsinformation dem Verschlüsselungshinweis folgt und außerhalb des verschlüsselten Teils der Kurzdatennachricht lokalisiert ist.
Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend, dass der Empfänger der Nachricht eine Fehlermeldung rückmeldet, wenn die Nachricht nicht entschlüsselt werden kann.
Verfahren nach Anspruch 10, wobei die Fehlermeldung als eine Kurzmeldung in der TETRA SDS-SHORT REPORT PDU gesendet wird oder als ein besonderer Wert der Auslieferungszustand-Parameter, die in der SDS-REPORT PDU verwendet werden.
Verfahren nach einem der Ansprüche 1 bis 11, wobei zwei verschlüsselungsanzeigende Protokollkennungswerte verwendet werden, wobei eine eine verschlüsselte SDS-Nachricht anzeigt und die andere eine verschlüsselte SDS-Nachricht, die SDS-TL verwendet, anzeigt.
Verfahren nach einem der Ansprüche 1 bis 11, wobei zwei Protokollkennungswerte verwendet werden, um eine verschlüsselte Nachricht anzuzeigen, wobei eine, deren erstes Bit auf "0" gesetzt ist, für verschlüsselte SDS-Nachrichten und verschlüsselte SDS-Nachrichten, die SDS-TL mit einem verschlüsselten TL-Header verwenden, verwendet wird, und der andere Protokollkennungswert, dessen erstes Bit auf "1" gesetzt ist, für verschlüsselte SDS-Nachrichten, die SDS-TL mit einem unverschlüsselten TL-Header verwenden, verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, mit den folgenden Schritten: Anordnen der Nachricht, welche in einer verschlüsselten Form versendet werden soll, teilweise oder vollständig in einer normalen Kurzdatennachrichtenstruktur des TETRA-Kommunikationssystems mit einigen oder allen der üblichen Kurzdatennachrichtsystemdatenheader und -felder; Verschlüsseln der so gebildeten Kurzdatennachricht oder des Kurzdatennachrichtenteils und Einbinden der verschlüsselten so gebildeten Kurzdatennachricht oder des Kurzdatennachrichtenteils mit dem Verschlüsselungshinweis in die Kurzdatennachricht, die übertragen wird.
Verfahren nach einem der vorhergehenden Ansprüche mit den folgenden Schritten: Bilden der Nachricht (64), die verschlüsselt werden soll; Bereitstellen eines Protokollkennungswerts (63) für die zu verschlüsselnde Nachricht; Verschlüsseln der zu verschlüsselnden Nachricht und deren Protokollkennungswerts; Packen der verschlüsselten Nachricht und des verschlüsselten Protokollkennungswertes in ein TETRR-SDS-Nachrichtenformat; Versehen der so gebildeten SDS-Nachricht mit einem weiteren Protokollkennungswert (61), der die SDS-Nachricht als eine eine verschlüsselte Nachricht enthaltende Nachricht identifiziert; und Übertragen der so konstruierten Kurzdatennachricht.
Verfahren nach Anspruch 15, wobei das Kurzdatennachrichtenformat in welches die Originalnachricht gepackt ist, entweder das SDS-Nachrichtenformat oder die SDS-Nachricht, die SDS-TL-Format verwendet, ist.
Verfahren nach Anspruch 14, 15 oder 16, ferner mit: Kennzeichnen der Originalkurzdatennachricht mit einer temporären Kennungsmarke, bevor sie verschlüsselt wird, wobei die Marke durch den Verschlüsselungsprozess unverändert bleibt, so dass die verschlüsselte Kurzdatennachricht identifiziert werden kann.
Verfahren nach Anspruch 14, 15, 16 oder 17, ferner mit den Merkmalen von einem der Ansprüche 1 bis 13.
Ein Verfahren zum Betreiben eines TETRA-Mobilkommunikationssystems, bei dem eine Typ-4-SDS-Nachricht gemäß einem der Ansprüche 1 bis 18 übertragen und empfangen wird.
Eine Vorrichtung zum Übertragen einer Kurzdatennachricht in einem TETRA-Mobilkommunikationssystem, wobei die Vorrichtung umfasst: Mittel (102) zum, wenn die Kurzdatennachricht eine verschlüsselte Nachricht umfasst, Aufnehmen eines Hinweises auf diese Tatsache in die Kurzdatennachricht, gekennzeichnet durch Mittel zum Verwenden bestimmter Protokollkennungswerte als Verschlüsselungshinweis und Mittel zum Bilden der Kurzdatennachricht (60), so dass sie die auf die Verschlüsselung hinweisende Protokollkennung (61), gefolgt von einem verschlüsselten Teil (65) der Kurzdatennachricht beinhaltend eine Protokollkennung (63) für die Nachricht, die verschlüsselt ist, und die verschlüsselte Nachricht (64), aufweist.
Vorrichtung nach Anspruch 20, wobei der Verschlüsselungshinweis der verschlüsselten Nachricht vorangeht.
Vorrichtung nach Anspruch 20 oder 21, wobei die Kurzdatennachricht, die übertragen wird, in eine Standardkurzdatennachrichtenstruktur des TETRA-Kommunikationssystems gepackt ist.
Vorrichtung nach Anspruch 20, 21 oder 22, wobei die Kurzdatennachricht als eine Typ-4-SDS-Nachricht versendet wird.
Vorrichtung nach Anspruch 23, wobei die Nachricht als eine Typ-4-SDS-Nachricht, die SDS-TL verwendet, versendet wird und der TL-Header (78) unverschlüsselt versendet wird.
Vorrichtung nach einem der Ansprüche 20 bis 24, ferner mit Mitteln (102, 103) zum Aufnehmen von Verschlüsselungsinformation (62) in die übertragene Kurzdatennachricht, um den Empfänger zu unterstützen, die Nachricht zu entschlüsseln.
Vorrichtung nach einem der Ansprüche 20 bis 25, wobei zwei verschlüsselungsanzeigende Protokollkennungswerte verwendet werden, wobei ein Wert eine verschlüsselte SDS-Nachricht anzeigt und der andere eine verschlüsselte SDS-Nachricht, die SDS-TL verwendet, anzeigt.
Vorrichtung nach einem der Ansprüche 20 bis 26, mit Mitteln (102) zum Anordnen der in einer verschlüsselten Form zu versendenden Nachricht teilweise oder vollständig in einer normale Kurzdatennachrichtenstruktur für das TETRA-Kommunikationssystem mit einigen oder allen der üblichen Kurzdatennachrichtsystemdatenheader und -felder; Mittel (103) zum Verschlüsseln der so gebildeten Kurzdatennachricht oder des Kurzdatennachrichtenteils; und Mittel (102) zum Einbinden der verschlüsselten so gebildeten Kurzdatennachricht oder des Kurzdatennachrichtenteils mit dem Verschlüsselungshinweis in die Kurzdatennachricht, die übertragen wird.
Vorrichtung nach einem der Ansprüche 20 bis 27, mit: Mitteln (105) zum Bilden der zu verschlüsselnden Nachricht; Mitteln (102) zum Bereitstellen eines Protokollkennungswertes für die zu verschlüsselnde Nachricht; Mitteln (103) zum Verschlüsseln der zu verschlüsselnden Nachricht und deren Protokollkennungswerts; Mitteln (102) zum Packen der verschlüsselten Nachricht (64) und des verschlüsselten Protokollkennungswertes (63) in einem TETRA-SDS-Nachrichtenformat; Mitteln (102) zum Versehen der so gebildeten SDS-Nachricht mit einem weiteren Protokollkennungswert (61), der die SDS-Nachricht als eine eine verschlüsselte Nachricht enthaltende Nachricht identifiziert; und Mitteln zum Übertragen der so konstruierten Kurzdatennachricht.
Vorrichtung nach Anspruch 28, wobei das Kurzdatennachrichtenformat, in welchem die Originalnachricht verpackt ist, entweder das SDS-Nachrichtenformat oder die SDS-Nachricht, die das SDS-TL-Format verwendet, ist.
Vorrichtung nach Anspruch 27, 28 oder 29, ferner mit Mitteln (102) zum Markieren der Originalkurzdatennachricht mit einer temporären Kennungsmarke bevor diese verschlüsselt wird, wobei die Marke bei dem Verschlüsselungsprozess unverändert bleibt, so dass die Vorrichtung die verschlüsselte Kurzdatennachricht identifizieren kann.
Vorrichtung nach Anspruch 27, 28, 29 oder 30, ferner mit Merkmalen von einem der Ansprüche 20 bis 26.
Vorrichtung zur Verwendung eines TETRA-Mobilkommunikationssystems mit Mitteln zum Übertragen oder Mitteln zum Empfangen einer Typ-4-SDS-Nachricht gemäß einem der Ansprüche 20 bis 31.
Eine Kurzdatennachricht für ein TETRA-Mobilkommunkationssystem mit: einer verschlüsselten Nachricht (64) und einem Hinweis, dass die Kurzdatennachricht eine verschlüsselte Nachricht umfasst, wobei der Verschlüsselungshinweis einen bestimmten Protokollkennungswert umfasst und die Kurzdatennachricht (60) dadurch gekennzeichnet ist, dass der auf die Verschlüsselung hinweisenden Pro tokollkennung (61) ein verschlüsselter Teil (65) der Kurzdatennachricht folgt, der eine Protokollkennung (63) für die Nachricht, die verschlüsselt ist, und die verschlüsselte Nachricht (64) umfasst.
Kurzdatennachricht nach Anspruch 33, wobei der Verschlüsselungshinweis der verschlüsselten Nachricht vorangeht.
Kurzdatennachricht nach Anspruch 33 oder 34, wobei die Kurzdatennachricht eine TETRA-Typ-4-SDS-Nachricht ist.
Kurzdatennachricht nach Anspruch 35, wobei die Nachricht eine Typ-4-SDS-Nachricht ist, die SDS-TL verwendet, und der TL-Header (78) unverschlüsselt ist.
Kurzdatennachricht nach einem der Ansprüche 33 bis 36, ferner mit einer Verschlüsselungsinformation (62), um den Empfänger zu unterstützen, die Nachricht zu entschlüsseln.
Kurzdatennachricht nach Anspruch 37, wobei die Verschlüsselungsinformation dem Verschlüsselungshinweis folgt und außerhalb des verschlüsselten Teils der Kurzdatennachricht lokalisiert ist.
Ein Computerprogrammelement mit Computersoftwarecodeanteilen zum Ausführen des Verfahrens nach einem der Ansprüche 1 bis 19, wenn das Programmelement auf datenverarbeitenden Mitteln ausgeführt wird.