SDS Aufbau

[florians]

Hallo!

Unsere Einsatzzentrale kann jetzt Statusnachrichten empfangen und auswerten.
Wo bekomme ich Infos zum Aufbau einer SDS her, damit ich den Status auch bestätigen kann bzw. andere Dinge wie Einsatzaufträge versenden kann?

[flachrelais_48]

Ein guter Anfang wären die technischen Spezifikationen. Z.B.:

ETSI EN 300 392-2
-> Air Interface (AI)

ETSI TS 100 392-18-1
-> Location Information Protocol (LIP)

ETSI TS 100 392-5
-> Peripheral Equipment Interface (PEI)

Ansonsten gibt es von den Endgeräteherstellern meistens noch diverse "Programming Guides", für deren Erhalt man meistens eine Vertraulichkeitsvereinbarung unterzeichnen muss.

Wenn du dich mit Linux-Shellskripten auskennst, kannst du dir auch mein "SDS2DB" anschauen, wie ich das für mich umgesetzt habe. Wenn du dich mit PHP auskenst, kannst du einen Blick in meine PHP-Klassen zum dekodieren von Text- und LIP-PDUs werfen.

http://www.funkmeldesystem.de/foren/...ghlight=SDS2DB

Viel Erfolg!

[Wizard]

Hallo!

Unsere Einsatzzentrale kann jetzt Statusnachrichten empfangen und auswerten.
Wo bekomme ich Infos zum Aufbau einer SDS her, damit ich den Status auch bestätigen kann bzw. andere Dinge wie Einsatzaufträge versenden kann?

Im welchen Bundesland und LK? Motorola oder Sepura?

Ich habe schon öfters folgendes gesehen:

Status-Quittierung von LS:
- "Leitstelle:01-Frei auf Funk"
- "Leitstelle:02-Frei auf Wache"
- "Leitstelle:06-nicht Einsatzbereit"

Anweisung von LS:
"Sprechaufforderung"

Gruß,
Wizard

[florians]

@flachrelais_48: Danke, damit werden wir's mal versuchen :-)
@Wizard: Danke, aber es ging mir nicht um die Inhalte ...

[Wizard]

@Wizard: Danke, aber es ging mir nicht um die Inhalte ...

Selbstverständlich musst Du die Inhalte der SDS kennen, um Status/Anweisungen zu "bestätigen" und Aufträge zu verarbeiten und zu "versenden".

Diese Dinge sind aber BOS-spezifisch und stehen in keiner Tetra-Spezifikation.

[ahk]

Ihr habt beide Recht...
FlorianS wollte vermutlich wissen, was er mit den 'Zeichen' machen muss, die an der PEI ankommen um die SDS zu lesen.
Wizard hat aber vollkommen richtig darauf hingewiesen, dass z.B. die Statuswerte, die im BOS-TETRA verwendet werden, nicht mehr den altbekannten entsprechen, was aber nicht in der ETSI drin steht.
Beispielsweise hat der 'Status 2 - Frei auf Wache' jetzt den Wert Hex 8004 (Dezimal 32772).

Grüße
Arne

[florians]

Tatsächlicherweise geht es nicht darum die empfangenen SDS auszuwerten, das ist bereits möglich (bei den Status SDS ist die Hex-Wert-Zuordnung zu den alten "Status-Nummern" ebenfalls bekannt).

Es geht darum, wie eine SDS aufgebaut ist, die versendet werden soll. Insbesondere interessiert hier der Aufbau des Headers in einer "Type 4"-SDS (also mit variabler Länge). Hierzu habe ich mich in den Spezifikationen bereits müde gesucht. In einem anderen Projekt habe ich gesehen, dass sich dies zusammensetzt aus

82 - wohl für SDS-Type 4
anschließend folgen 6 Zeichen, je in 2er Blöcken für
Flags, Counter und Start oder so ähnlich.

Der Aufbau dieses Headers z.B. lässt sich jedoch derzeit nur "erahnen".

Zudem ist mir noch nicht ganz eindeutig klar, wie sich die Länge der SDS berechnet. In dem vorbenannten Projekt wurden hier einfach die Anzahl der Zeichen (Bytes) mit 4 multipliziert und anschließend für den Header 8x4=32 hinzuaddiert. Allerdings klappt dies nicht immer. Insbesondere scheint es Probleme zu geben, wenn die binäre Darstellung auf Nullen endet und/oder mit Nullen beginnt, z.B. 1001 0100 0100. Hier ist jetzt nicht klar, ob die Länge 12 oder (laut Spezifikation) 10 ist. Ich bekomme häufig die Meldung "25" oder "35" (nicht ganz sicher), was laut Spezifikation "ungültige Zeichen" bedeutet, habe aber die SDS nur aus Spaces 0x20 (Dez 32) aufgebaut.

Bin für jede Hilfe dankbar!

[flachrelais_48]

Ich hatte auch nicht versprochen, dass es einfach wird. Hast du denn mal in meine PHP-Funktionen zum SDS dekodieren geschaut? Ich habe mir soviel Mühe gegeben, ordentliche Kommentare im Code zu hinterlassen.

// decode_PDU
// liefert ein Array mit decodierten Protokoll-Feldern eines übergebenen hexadezimalen User-Daten-Teils einer TETRA-SDS (SDS-PDU)
// ETSI EN 300 392-2 V3.4.1
// 29.4.1 PDU general structure (Table 29.10: PDU layout)
// 29.4.3.9 Protocol identifier (Table 29.21: Protocol identifier information element contents)
function decode_PDU ($PDU)
{
$ret=array();
$PDUbin=hextobin($PDU); // Hex-String in Binär-String wandeln
// Protocol Identifyer 8 Bit [0-255]
$ret["StringPos"]=0;
$SubStrLen=8;
$ret["ProtoIdent"] = array();
$ret["ProtoIdent"]["value"] = bindec(substr("$PDUbin",$ret["StringPos"],$SubStrLen));
$ret["StringPos"]+=$SubStrLen;
switch($ret["ProtoIdent"]["value"])
{
case 1: // Over The Air re-Keying for end to end encryption
$ret["ProtoIdent"]["name"] = "OTAK";
break;
case 2: // Simple Text Messaging
$ret["ProtoIdent"]["name"] = "Simple Text Messaging";
break;
case 3: // Simple location system
$ret["ProtoIdent"]["name"] = "Simple location system";
break;
case 4: // Wireless Datagram Protocol WAP
$ret["ProtoIdent"]["name"] = "Wireless Datagram Protocol WAP";
break;
case 5: // Wireless Control Message Protocol WCMP
$ret["ProtoIdent"]["name"] = "Wireless Control Message Protocol WCMP";
break;
case 6: // Managed DMO
$ret["ProtoIdent"]["name"] = "Managed DMO";
break;
case 7: // PIN authentication
$ret["ProtoIdent"]["name"] = "PIN authentication";
break;
case 8: // End-to-end encrypted message
$ret["ProtoIdent"]["name"] = "End-to-end encrypted message";
break;
case 9: // Simple immediate text messaging
$ret["ProtoIdent"]["name"] = "Simple immediate text messaging";
break;
case 10: // Location information protocol
$ret["ProtoIdent"]["name"] = "Location Information Protocol";
foreach(get_LipPDU($PDUbin,$ret["StringPos"]) as $key => $value) { $ret[$key] = $value; }
break;
case 11: // Net Assist Protocol (NAP)
$ret["ProtoIdent"]["name"] = "Net Assist Protocol (NAP)";
break;
case 12: // Concatenated SDS message
$ret["ProtoIdent"]["name"] = "Concatenated SDS message";
break;
case 13: // DOTAM
$ret["ProtoIdent"]["name"] = "DOTAM";
break;
case 130: // Text Messaging
$ret["ProtoIdent"]["name"] = "Text Messaging";
foreach(get_TextPDU($PDUbin,$ret["StringPos"]) as $key => $value) { $ret[$key] = $value; }
break;
case 131: // Location system
$ret["ProtoIdent"]["name"] = "Location system";
break;
case 132: // Wireless Datagram Protocol WAP
$ret["ProtoIdent"]["name"] = "Wireless Datagram Protocol WAP";
break;
case 133: // Wireless Control Message Protocol WCMP
$ret["ProtoIdent"]["name"] = "Wireless Control Message Protocol WCMP";
break;
case 134: // Managed DMO
$ret["ProtoIdent"]["name"] = "Managed DMO";
break;
case 136: // End-to-end encrypted message
$ret["ProtoIdent"]["name"] = "End-to-end encrypted message";
break;
case 137: // Immediate text messaging
$ret["ProtoIdent"]["name"] = "Immediate text messaging";
break;
case 138: // Message with User Data Header
$ret["ProtoIdent"]["name"] = "Message with User Data Header";
break;
case 140: // Concatenated SDS message
$ret["ProtoIdent"]["name"] = "Concatenated SDS message";
break;
default:
if((($ret["ProtoIdent"]["value"] > 63) && ($ret["ProtoIdent"]["value"] < 127)) || (($ret["ProtoIdent"]["value"] > 191) && ($ret["ProtoIdent"]["value"] < 255)))
{
$ret["ProtoIdent"]["name"] = "user application defined (value=".$ret["ProtoIdent"]["value"].")";
}
else
{
$ret["ProtoIdent"]["name"] = "Reserved (value=".$ret["ProtoIdent"]["value"].")";
}
}
return $ret;
}

Die Zahlen hinter den Case-Verzweigungen sind die Dezimalwerte der Protocol Identifier. Die folgenden Protokoll-Bestandteile sind teils variabel und abhängig von vorangehenden Feldern.

Die Länge der SDS-PDU sollte sich aus dem Produkt der Anzahl der Hexziffern mit 4 (Bit je Hexziffer) ergeben. Das hat mir aber bis jetzt auch noch nie Sorgen bereitet.