Amateurfunk Forum - Archiv

Fragen und Antworten zum Thema Funk


Impressum

Verantwortlich für dieses Angebot gemäß § 5 TMG / § 55 RStV:
Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

Datenschutzerklärung

Diese Datenschutzerklärung klärt Sie über die Art, den Umfang und Zweck der Verarbeitung von personenbezogenen Daten (nachfolgend kurz „Daten“) innerhalb unseres Onlineangebotes und der mit ihm verbundenen Webseiten, Funktionen und Inhalte auf (nachfolgend gemeinsam bezeichnet als „Onlineangebot“). Im Hinblick auf die verwendeten Begrifflichkeiten, wie z.B. „Verarbeitung“ oder „Verantwortlicher“ verweisen wir auf die Definitionen im Art. 4 der Datenschutzgrundverordnung (DSGVO).

Verantwortlicher

Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Arten der verarbeiteten Daten:

- Meta-/Kommunikationsdaten (siehe Abschnitt „Erhebung von Zugriffsdaten und Logfiles“)

Kategorien betroffener Personen

Besucher und Nutzer des Onlineangebotes (Nachfolgend bezeichnen wir die betroffenen Personen zusammenfassend auch als „Nutzer“).

Zweck der Verarbeitung

- Zurverfügungstellung des Onlineangebotes, seiner Funktionen und Inhalte
- Sicherheitsmaßnahmen.

Verwendete Begrifflichkeiten

„Personenbezogene Daten“ sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung (z.B. Cookie) oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind.

„Verarbeitung“ ist jeder mit oder ohne Hilfe automatisierter Verfahren ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten. Der Begriff reicht weit und umfasst praktisch jeden Umgang mit Daten.

„Pseudonymisierung“ die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden.

Als „Verantwortlicher“ wird die natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet, bezeichnet.

„Auftragsverarbeiter“ eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet.

Maßgebliche Rechtsgrundlagen

Nach Maßgabe des Art. 13 DSGVO teilen wir Ihnen die Rechtsgrundlagen unserer Datenverarbeitungen mit. Sofern die Rechtsgrundlage in der Datenschutzerklärung nicht genannt wird, gilt Folgendes: Die Rechtsgrundlage für die Einholung von Einwilligungen ist Art. 6 Abs. 1 lit. a und Art. 7 DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer Leistungen und Durchführung vertraglicher Maßnahmen sowie Beantwortung von Anfragen ist Art. 6 Abs. 1 lit. b DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer rechtlichen Verpflichtungen ist Art. 6 Abs. 1 lit. c DSGVO, und die Rechtsgrundlage für die Verarbeitung zur Wahrung unserer berechtigten Interessen ist Art. 6 Abs. 1 lit. f DSGVO. Für den Fall, dass lebenswichtige Interessen der betroffenen Person oder einer anderen natürlichen Person eine Verarbeitung personenbezogener Daten erforderlich machen, dient Art. 6 Abs. 1 lit. d DSGVO als Rechtsgrundlage.

Sicherheitsmaßnahmen

Wir treffen nach Maßgabe des Art. 32 DSGVO unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen, geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Zu den Maßnahmen gehören insbesondere die Sicherung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten durch Kontrolle des physischen Zugangs zu den Daten, als auch des sie betreffenden Zugriffs, der Eingabe, Weitergabe, der Sicherung der Verfügbarkeit und ihrer Trennung. Des Weiteren haben wir Verfahren eingerichtet, die eine Wahrnehmung von Betroffenenrechten, Löschung von Daten und Reaktion auf Gefährdung der Daten gewährleisten. Ferner berücksichtigen wir den Schutz personenbezogener Daten bereits bei der Entwicklung, bzw. Auswahl von Hardware, Software sowie Verfahren, entsprechend dem Prinzip des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO).

Zusammenarbeit mit Auftragsverarbeitern und Dritten

Sofern wir im Rahmen unserer Verarbeitung Daten gegenüber anderen Personen und Unternehmen (Auftragsverarbeitern oder Dritten) offenbaren, sie an diese übermitteln oder ihnen sonst Zugriff auf die Daten gewähren, erfolgt dies nur auf Grundlage einer gesetzlichen Erlaubnis (z.B. wenn eine Übermittlung der Daten an Dritte, wie an Zahlungsdienstleister, gem. Art. 6 Abs. 1 lit. b DSGVO zur Vertragserfüllung erforderlich ist), Sie eingewilligt haben, eine rechtliche Verpflichtung dies vorsieht oder auf Grundlage unserer berechtigten Interessen (z.B. beim Einsatz von Beauftragten, Webhostern, etc.).

Sofern wir Dritte mit der Verarbeitung von Daten auf Grundlage eines sog. „Auftragsverarbeitungsvertrages“ beauftragen, geschieht dies auf Grundlage des Art. 28 DSGVO.

Übermittlungen in Drittländer

Sofern wir Daten in einem Drittland (d.h. außerhalb der Europäischen Union (EU) oder des Europäischen Wirtschaftsraums (EWR)) verarbeiten oder dies im Rahmen der Inanspruchnahme von Diensten Dritter oder Offenlegung, bzw. Übermittlung von Daten an Dritte geschieht, erfolgt dies nur, wenn es zur Erfüllung unserer (vor)vertraglichen Pflichten, auf Grundlage Ihrer Einwilligung, aufgrund einer rechtlichen Verpflichtung oder auf Grundlage unserer berechtigten Interessen geschieht. Vorbehaltlich gesetzlicher oder vertraglicher Erlaubnisse, verarbeiten oder lassen wir die Daten in einem Drittland nur beim Vorliegen der besonderen Voraussetzungen der Art. 44 ff. DSGVO verarbeiten. D.h. die Verarbeitung erfolgt z.B. auf Grundlage besonderer Garantien, wie der offiziell anerkannten Feststellung eines der EU entsprechenden Datenschutzniveaus (z.B. für die USA durch das „Privacy Shield“) oder Beachtung offiziell anerkannter spezieller vertraglicher Verpflichtungen (so genannte „Standardvertragsklauseln“).

Rechte der betroffenen Personen

Sie haben das Recht, eine Bestätigung darüber zu verlangen, ob betreffende Daten verarbeitet werden und auf Auskunft über diese Daten sowie auf weitere Informationen und Kopie der Daten entsprechend Art. 15 DSGVO.

Sie haben entsprechend. Art. 16 DSGVO das Recht, die Vervollständigung der Sie betreffenden Daten oder die Berichtigung der Sie betreffenden unrichtigen Daten zu verlangen.

Sie haben nach Maßgabe des Art. 17 DSGVO das Recht zu verlangen, dass betreffende Daten unverzüglich gelöscht werden, bzw. alternativ nach Maßgabe des Art. 18 DSGVO eine Einschränkung der Verarbeitung der Daten zu verlangen.

Sie haben das Recht zu verlangen, dass die Sie betreffenden Daten, die Sie uns bereitgestellt haben nach Maßgabe des Art. 20 DSGVO zu erhalten und deren Übermittlung an andere Verantwortliche zu fordern.

Sie haben ferner gem. Art. 77 DSGVO das Recht, eine Beschwerde bei der zuständigen Aufsichtsbehörde einzureichen.

Widerrufsrecht

Sie haben das Recht, erteilte Einwilligungen gem. Art. 7 Abs. 3 DSGVO mit Wirkung für die Zukunft zu widerrufen

Widerspruchsrecht

Sie können der künftigen Verarbeitung der Sie betreffenden Daten nach Maßgabe des Art. 21 DSGVO jederzeit widersprechen. Der Widerspruch kann insbesondere gegen die Verarbeitung für Zwecke der Direktwerbung erfolgen.

Löschung von Daten

Die von uns verarbeiteten Daten werden nach Maßgabe der Art. 17 und 18 DSGVO gelöscht oder in ihrer Verarbeitung eingeschränkt. Sofern nicht im Rahmen dieser Datenschutzerklärung ausdrücklich angegeben, werden die bei uns gespeicherten Daten gelöscht, sobald sie für ihre Zweckbestimmung nicht mehr erforderlich sind und der Löschung keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Sofern die Daten nicht gelöscht werden, weil sie für andere und gesetzlich zulässige Zwecke erforderlich sind, wird deren Verarbeitung eingeschränkt. D.h. die Daten werden gesperrt und nicht für andere Zwecke verarbeitet. Das gilt z.B. für Daten, die aus handels- oder steuerrechtlichen Gründen aufbewahrt werden müssen.

Nach gesetzlichen Vorgaben in Deutschland, erfolgt die Aufbewahrung insbesondere für 10 Jahre gemäß §§ 147 Abs. 1 AO, 257 Abs. 1 Nr. 1 und 4, Abs. 4 HGB (Bücher, Aufzeichnungen, Lageberichte, Buchungsbelege, Handelsbücher, für Besteuerung relevanter Unterlagen, etc.) und 6 Jahre gemäß § 257 Abs. 1 Nr. 2 und 3, Abs. 4 HGB (Handelsbriefe).

Hosting und E-Mail-Versand

Die von uns in Anspruch genommenen Hosting-Leistungen dienen der Zurverfügungstellung der folgenden Leistungen: Infrastruktur- und Plattformdienstleistungen, Rechenkapazität, Speicherplatz und Datenbankdienste, E-Mail-Versand, Sicherheitsleistungen sowie technische Wartungsleistungen, die wir zum Zwecke des Betriebs dieses Onlineangebotes einsetzen.

Hierbei verarbeiten wir, bzw. unser Hostinganbieter Meta- und Kommunikationsdaten von Besuchern dieses Onlineangebotes auf Grundlage unserer berechtigten Interessen an einer effizienten und sicheren Zurverfügungstellung dieses Onlineangebotes gem. Art. 6 Abs. 1 lit. f DSGVO i.V.m. Art. 28 DSGVO (Abschluss Auftragsverarbeitungsvertrag).

Erhebung von Zugriffsdaten und Logfiles

Wir, bzw. unser Hostinganbieter, erhebt auf Grundlage unserer berechtigten Interessen im Sinne des Art. 6 Abs. 1 lit. f. DSGVO Daten über jeden Zugriff auf den Server, auf dem sich dieser Dienst befindet (sogenannte Serverlogfiles). Zu den Zugriffsdaten gehören Name der abgerufenen Webseite, Datei, Datum und Uhrzeit des Abrufs, übertragene Datenmenge, Meldung über erfolgreichen Abruf, Browsertyp nebst Version, das Betriebssystem des Nutzers, Referrer URL (die zuvor besuchte Seite), IP-Adresse und der anfragende Provider.

Logfile-Informationen werden aus Sicherheitsgründen (z.B. zur Aufklärung von Missbrauchs- oder Betrugshandlungen) für die Dauer von maximal 7 Tagen gespeichert und danach gelöscht. Daten, deren weitere Aufbewahrung zu Beweiszwecken erforderlich ist, sind bis zur endgültigen Klärung des jeweiligen Vorfalls von der Löschung ausgenommen.

Vom Websiteinhaber angepasst
Erstellt mit Datenschutz-Generator.de von RA Dr. Thomas Schwenke




 [ 78 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5, 6
Autor Nachricht
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hi,
ich hätte gern 3 Tage Dauerbetrieb ausm Akku, 2 Wochen Notstrom mit Generator.
Minimalversion wäe z.b. Arduino/Raspberry mit 4 Zeilen LCD Display drann. Netbook oder Tablet könnte auch gehen. Normaler Büro Laptop hat sicher wieder zu hohen Stromverbrauch..

Hmm..noch ne Idee zu einem Zeitschlitz Verfahren. Jeder Rechner bekommt eine fortlaufende Nummer und damit einen Zeitschlitz innerhalb einer Minute zugeteilt. Würde Kollisionen durch zufälliges senden stark runter schrauben.
Ist das machbar ?

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Für point-to-point wäre wiederum RTTY sicherer und einfacher.[/quote]

Leider entspricht weder RTTY noch PSKxyz irgend etwas, womit die BOS etwas anfangen können. Ihr wisst doch selbst, wie schnell man bei allen derartigen Betriebsarten Buchstabensalat hat. Jetzt stellt euch bitte Beamte in einer Regierungsbehörde oder einer Kreisverwaltungsbehörde vor, welche dann diesen Buchstabensalat lesen und "verstehen" sollen. Es ist in der Tat ein Unterschied ob man Unterkünfte für 200 oder 2000 Personen benötigt ;-) BOS benötigen - wenn Datenkommunikation - dann eine sichere und fehlerfreie solche.

Im Übrigen denke ich bei Datenfunk für die Behörden definitiv NICHT daran, jede einzelnen BOS mit solchen Geräten auszustatten - shcon gar nicht "Feldeinheiten" - sprich: BOS welche draussen vor der Türe den Drecksjob erledigen, während man in den Krisenstäben beim warem Kaffee sitzt. Es geht um den Datenaustausch genau jender Krisenstäbe, welche eben eine feste Unterkunft haben und somit auch Platz und Möglichkeiten für Geräte, und vor allem eine weitegehend gesicherter Stromversrogung.

Setzt man diese Maßgabe voraus werden nämlich aus den vieln viel Benutzer plötzlich nur noch ganz wenige. Als Beispiel: Unsere Bezirksregierung hätte famit genau nur noch 13 Funkpartner: Alle 12 Kreisverwaltungsbehörden und das Staatsministerium des Inneren. Letzteres ist aber besser auf KW mit PACTOR/WINMORE zuerreichen.

Packet Radio käme damit folglich gerade mal für 13 Funkstationen in Frage - was die Sache wieder ganz anders aussehen lässt. Zudem existiert hier bei uns kein Packet Radio Netzwerk mehr (höchstens Inseln mit Anbindung an Hamnet).

Bitte legt doch auch nciht eure Erfahrungen im "Normalzustand" für ein Notfunknetzwerk zugrunde. Sollte es z.B. zu großflächigen Stromausfällen kommen (und nur bei solchen Ereignissen würde Amateurfunk überhaupt als Notfunk für die BOS zum Einsatz kommen in DL), dann ist in der betroffenen Region garantiert relativ wenig Funkverkehr zu erwarten ;-) Somit sind die Frequenzen nicht überlastet und auch das QRM sollte sich in geringsten Maßen halten.

73, Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ich will ja nur die Grenzen von PR (AX25) aufzeigen. Zu der Aussage RTTY und PSK lege ich jetzt aber schon Protest ein. Beim klassischen RTTY kriegst Du mit relativ einfachen Einstellungen eine sauberen Datenverkehr. Das kannst Du mit Soundkarten-PSK wirklich nicht vergleichen. Ich höre oft genug auf KW mit (läuft immer wieder mal als "Hintergrundmusik" mit. Wenn jemand (heute noch) RTTY macht, hat er i.d.R. eine Filterkonverter und RTTY läuft ok oder fast nur Salat, jedenfalls solange nicht S/W-Soundkarte gemacht wird. RTTY war lange Zeit bei allen BOS und Behörde mit FAX das einzige Kommunikationsmittel, was sich auch bewährt hat. Die Soundkartenjünger setzen oft Signale ab, daß es einem grausen kann - da sind Konverter-Lösungen haushoch überlegen.

Mit PR kriegst Du mit etwas Pech auch "Salat". Da mußt Du immer mit rechnen, weil die Error-Routinen doch relativ einfach sind. Der einzige Vorteil ist der Sessionbetrieb. Bei ~12± Stationen, die sich gegenseitig sehen können, ist der Betrieb unproblematisch. Insofern kann mit diesen Beschränkungen dann sinnvoll gearbeitet werden. Sobald digipeated wird und "hidden Terminals" auftauchen, wird es allerdings problematisch.

Zum Notfall: es gibt genügend Berichte über Zusammenbrüche der digitalen BOS-Verbindungen bei bisherigen (kleineren) Notfällen. Und das bei EVU-Verlust nur noch drei einsame Funker aktiv sind, das ist aber jetzt ein Traum von Dir, :-) . Das habe ich im OV auf der OV-QRG bei Stromausfall aber auch schon anders erlebt. Es gibt immer wieder Quasselstrippen, die dann ausgiebig erklären, welche Geräte jetzt noch gehen und welche Notbeleuchtungsbirne am Akku mit xyz Ah hängt, usw. Da betet man zig Stoßgebete, daß deren Akku bald leer ist, hi.

Du müßtest Deine Lösung evtl. mal mit 4-5 HAM bei einer Übung einbringen. Nur mit Theorie ................... Du siehst ja hier im Thread bereits, was mir zu PR im allgemeinen dazu einfält. Es hängt sehr stark von Deiner Netzorganistation ab, auch bei 4-5 Stationen bereits. Evtl. kannst Du ja auch befristet ein normales FM-Relais einbinden - zur Reichweiten-Erhöhung ganz normal per FM, KEIN Digipeaten.. Ich habe das jedenfalls bei unserem OV Relais DB0XF problemlos testen können, via DCD Steuerung im TNC kann Sprache und PR ohne weiter Klimmzüge miteinander laufen. Der TNC sendet erst, wenn keiner spricht. Allerdings quatschen manche dann in PR rein ...... meistens weil sie es nicht mitgekriegt haben, das PR-Testbetrieb läuft und sie meinen, einen Störer nieder bügeln zu müssen.

73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
@Guido

[quote]womit die BOS etwas anfangen können.[/quote]
Jetzt habe ich es vermutlich erst richtig verstanden, Du willst ein PR Netz aufbauen, es zur Verfügung stellen und im Notfall sollen es die "BOS Funker" nutzen wenn bei denen in den Netzen nichts mehr geht? Interessant.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ich sehe sowas in erster Linie als Unterstützungs-Netz. Wenn mal ne Oma aus dem Dorf ins Krankenhaus muss oder irgendwo ein Unfall ist...wenn ein Bergdorf eingeschneit ist...dann kann durch Amateurfunk der erste Kontakt erfolgen.
Die BOS Dienste können ja nicht überall gleichzeitig Streife fahren.
So können die ihre Kräfte da bündeln wo wirklich Arbeit zu tun ist.

Kontakte zwischen den BOS Kommandostellen sehe ich wirklich nur als Notfall-Bakup an..wenns unbedingt sein muss. Nicht als vorrangige Aufgabe.

Und ja..es sollte weitestgehend "idiotensicher " sein..keine Buchstaben/Ziffern Umschaltung oder so Gags.
Die "Putze" sollte die Anlage nach 5 Min Einweisung bedienen können.
Niemand weiss wer bei nem echten Notfall gerad am Mikro / Tastatur ist...

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote].... Niemand weiss wer bei nem echten Notfall gerad am Mikro / Tastatur ist... [/quote]Hallo Uwe,
wir reden ja über Katastrophen, bzw. großräumige Notfälle bzw. "Großereignisse". Da kannst Du an einer Knotenstelle niemanden gebrauchen, der den entsprechenden Funkverkehr vorher nicht intus hat, d.h. Schulung und Übung. Das kann jetzt kein Funktechniker sein, der hilft Dir nur beim Geräteaufbau. Du brauchst für den THW-, Feuerwehr-, Rettungsdienst-, Behörden/Polizei-Teil jemanden, der deren Sprache spricht. Auch wenn es nur ein Kaffeeholer-Dienst ist, der muß VORHER in die Bedienung eingewiesen werden und seine Kontaktleute kennen. Irgend ein PTT-Drücker hat an Kommunikationsgeräten in einer solchen Situation nichts verloren. Da hilft Dir auch kein Funkamateur mit IQ170 und ....... und UNO-007-Lizenz.

Funk ist nur ein Mittel zum Zweck und nicht die Hauptsache.

Sorry, Du kennst mich ja, das ging jetzt nicht an Dich, sondern ganz allgemein. Fiel mir spontan ein, als ich den zitierten Satzteil gelesen habe. Viele haben etwas falsche Vorstellungen vom Funk bei den BOS/Hilfsdiensten. Wenn man nicht weiß, wer an Mike/Tastatur sitzt, läuft etwas fürchterlich falsch ....... Dann ist der u.U. ein Teil der Katastrophe und nicht eine Hilfe. :-)

73 Peter (ehrenamtlicher RS i.R., BRK)

ps: ich nutze seit Jahren für RTTY einen PK232mbx, d.h. der kann alle erwähnten Modi, u.a. auch Pactor und AX25 incl. eigener Mailbox. Ist einfach zu konfiguruieren und robust, auf KW und UKW über den Mike/PTT Anschluß. Der alte T100S ist nostalgisches Spielzeug.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Spannendes Thema, so richtig (organisatorisch) habe ich die Idee des TO aber noch nicht verstanden. Wir sprechen von Not- und Katastrophenfällen und nicht vom Armageddon, oder? Nehmen wir mal den flächendeckenden (Landkreis, Bundesland) Stromausfall über mehrere Tage als Beispiel, sagen wir mal, zwei Wochen.

Über Not- und Katastrophenfälle gibt es im AFuG zwei konkrete Hinweise, § 2 und § 5 AFuG. Funkamateure sollen in diesem Fall unterstützen und sie dürfen im Not- und Katastrophenfall Nachrichten von und an Dritte übermitteln. Was ich mir vorstellen könnte sind die folgenden Szenarien.

1. Funkamateure bilden in einem begrenzten Gebiet (Landkreis, Bundesland) eine stationäre (da wo sie wohnen) Kommunikationsinfrastruktur (PR, Voice) die auch unabhängig vom Stromnetz funktioniert. Das muss man erheben, dokumentieren, testen und mit den BOS Funkdiensten kommunizieren.
2. Funkamateure stellen an zentralen Punkten (Leitstellen) der BOS Dienste AFU Infrastruktur und sich selbst zur Verfügung um den Austausch von Informationen zwischen den Funkdiensten und untereinander zu gewährleisten. Das muss man erarbeiten, dokumentieren und gemeinsam üben!

Wenn man diese Informationen zusammen hat kann man sich daran machen, eine individuelle Lösung für ein Gebiet zu erarbeiten. PR kann da durchaus ein Teil einer Lösung sein, muss aber nicht überall funktionieren.

Gibt es seitens des TO diesbezüglich ein Konzept?


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Es gibt in Bayern Vereinbarungen mit Staat und Behörden. Afu wird teilweise regional bei Übungen mit eingeladen. Aber da ist lt. Signatur dj1ng besser als ich informiert. Ich war bei den "Drecksjobs" :-) (NAW,RTW) - und die Zusammenarbeit kam nach meiner aktiven Zeit. Da bin ich nicht mehr aktiv geworden, aber unser OV hat Kontakte auf Landkreisebene (Oberbayern, Distrikt C, aber es funktioniert auch in anderen Regionen).

73 Peter

@Uwe - vergessen zu Zeitschlitze: das hat sich ebenso wie Polling und Prioritäts-Verfahren nicht bewährt. Starre Zeitschlitze machen den Durchsatz gravierend kaputt und dynamische Zeitschlitze sind sehr komplex zu handhaben. Im Retry-Fall hast Du keine sinnvolle Kontrolle mehr. Bei 1200 kostet jedes zusätzliche Protokoll-Fitzelchen zuviel Zeit. Sorry, das sind uralte IT-Erfahrungen.


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ich hätte eben gern was wo schwache Signale nicht totgeschlagen werden und man ne definierte Antwortzeit hat. Überlegt euch was ;)

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hallo Uwe &all:
ich hole mal etwas OT aus zu dem Problem "Antwortzeiten". Ich habe bei IBM die Entwicklung von der Lochkarte bis Online per Bildschirm und dann die Vernetzung ab den 70ern miterlebt und war intensiv eingebunden. Für die Bildschirm-Arbeitsplätze gab es im Laufe der Geschichte die unterschiedlichsten Anbindungen. Das ganze Geschäft hängt von der Nachrichtengröße und der (Info-)Kanalgeschwinigkeit ab. Dazu kamen anfangs noch Umschaltzeiten RX/TX dazu, weil Duplex damals ein teueres Vergnügen war. Die Mainframe Struktur war lange Zeit ein reines Sternnetz mit intelligenten Knoten (Controllern). Mit der Auslagerung auf lokale Netze mit eigenen kleineren Rechnern (heute üblicherweise bei Banken/Versicherngen etc. mit Server(Client je Lokation und Anbindung Server an Mainframe) kamen auch lokale Ring-Netze auf. Einer der Haupt-Konkurrenten (Mitbewerber ist der offizielle Titel) war Data Saab mit einer Ethernet-CDMA-Vernetzung via Telephon-Zweidraht. Das hatte in der Industrie auf großen Werksgeländen den Vorteil, daß die Telephonleitungen mitbenutzt werden konnten, anstelle eigens verlegter Koaxkabel für die damaligen IBM 3270 Bildschirme (ein fast-Standard).

Ich war in sehr vielen Planungen und Erstinstallationen eingebunden, da ich aus der Technik kam. D.h. Messungen, Berechnungen, Simulationen, und Support 2nd level und mit Labor zusammen). Für mich war damals dann AX25 eine sehr gute Ergänzung, weil ich viele Theorien und Messungen (d.h. QRL Erfahrung) auch mit den unterschiedlichsten TNC-Parametern nachvollziehen konnte. Zu den Anfängen der Bildschirmvernetzung gab es auch noch eine Welt unter 1200, aber die war für Bildschirme dann eher mit Brieftauben vergleichbar :-) . Wurde nur für Datenübertragung in kleinerem Umfang benutzt. Ein voller Bildschirminhalt alter Sorte waren 25x80 Zeichen zu je 8 bit bei 1200, d.h. 1,5 bis 1,8 volle Zeilen je Sekunde (8bit oder 8+2bit seriell), teilweise durch Codierung auf 6bit reduziert mit 2,5 Zeilen/sec. Man stieg sehr schnell für Bildschirmarbeiten auf 9600 um, 64k kam erst später - aus Kostengründen. Die 1200 blieben noch eine Weile für einzelne Schreibmaschinenterminals. Man kann sich das heute kaum noch vorstellen.

Wir haben heute im Megabit- und Gigabit-bereich teilweise keine Gefühl mehr für zeitkritische Protokollarien. Die Leitungen sind auch kaum noch voll ausgelastet (Mittelwert). Die jüngere Generation hat nicht mehr erlebt, was es heißt, wenn bei Polling eine Station mit drin ist, die mit Romanen die Leitung blockiert. Das ist bei 1200 so wie auf einem Relais ohne Zeitsteuerung, wo einer die PTT nicht mehr los läßt.

Auf Ethernet AX25 bezogen: Es ist eine unbestrittene Erfahrung aus der Zeit, daß der Gesamtdurchsatz am besten ist, wenn alle gleich behandelt werden, die 1200er Leitung/QRG nur bis 30% ausgelastet ist, und Fehlerretries kontrolliert mit Zeitverzögerung gemacht werden. Man kann durch Begrenzung der Blocklänge und Zeitabstand auch beeinflussen, daß eine Massennachricht nicht alles tot macht. Das sind so die wichtigsten Eckpunkte.

Die ganzen Protokollkunstgriffe für eine höher Auslastung (mehr wie 60% sind bei CDMA auf einem Kanal trotzdem nicht drin) erhöhen lediglich die Wartezeit auf einen freien Kanal, bzw. damit auch Antwortzeit. Bis 30% gibt es kaum spürbare Abhängigkeiten von der Auslastung, danach geht zwar insgesamt mehr, aber für den Einzelnen langsamer.

Für unseren "Notfallfunk" heißt das letztlich: Man muß die Datenmenge grob abschätzen und bei Dialogbetrieb versuchen, die Belegung auf ~1/3 zu beschränken. Spätestens ab 50-60% Auslastung ist bei CDMA auf einer QRG und speziell mit 1200 kein vernünftiger (Notfall-)Dialog mehr möglich. Zu reiner Datenübertragung ..... ----- das macht man dann aber exklusiv zwischen zwei Stationen, da haben alle anderen Pause.

Ich hoffe, nicht allzu gelangweilt zu haben und die "früher ..." Geschichte nicht zu sehr strapaziert zu haben. Ansonsten .... Rückfragen zu dem technischen Thema jederzeit. Aus der Afu-Notfallpolitik halte ich mich etwas raus, weil ich da im Ernstfall wohl eher wieder im Rettungsdienst vor Ort lande, mit anfassen und keine Funkbetreuung.

73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Ok, sagen wir mal ein Kanal mit 30% Auslastung..reicht das denn ?
Stellen wir uns mal vor Köln hat 2 Wochen kein Strom. Dann müssen zumindest Nahrungsmittel und Wasser in die Stadt transportiert werden. Die Ampeln/Wasserpumpen tuns natürlich auch nicht...

Das wird einen einzigen grossen Stau geben...wenn man das frei laufen lässt...

Gibts dafür Pläne ?

73 de DL3FOX Uwe


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]Ok, sagen wir mal ein Kanal mit 30% Auslastung..reicht das denn ?

[b:3iy9pc18][i:3iy9pc18]Für was?[/i:3iy9pc18][/b:3iy9pc18]

Stellen wir uns mal vor Köln hat 2 Wochen kein Strom. Dann müssen zumindest Nahrungsmittel und Wasser in die Stadt transportiert werden. Die Ampeln/Wasserpumpen tuns natürlich auch nicht...

Das wird einen einzigen grossen Stau geben...wenn man das frei laufen lässt...

Gibts dafür Pläne ?
[/quote]

Ist wohl anzunehmen.
Ich bin auch ziemlich sicher, dass in denen keine Wichtigtuer mit ihren "Notfunkkoffern" vor kommen...


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
... und schon rutscht das Thema ins Organisatorische, aber das scheint ja wohl unvermeidlich ;-)

Da ich mehrfach gefragt wurde, aber eben nicht so schnell antworten kann, kommt mein Senf eben hier dazu.

1. FM Sprechfunk wird nicht ad acta gelegt. FM Sprechfunk ist die erste Maßnahme, mit welcher Amateueurfunk den BOS helfen kann - denn nach 48 bis spät. 72 Stunden Stromausfall ist das digitale Tetra-Funknetz bereits Geschichte. Dann kann man höchstens nur noch im Direct Mode mit Gateways und Repeatern arbeiten. Das ist für lokale Einsatzstellen zu gebrauchen, aber nicht für die Kommandoebene (nein ich rede nicht von der RAF). Denn TETRA arbeitet digital im 70cm Band - und jeder von euch weiss, wie schnell 70cm Verbindungen schon alleine durch einen Baum abgeschattet werden.

2. Die Verbreitung von RTTY-Modems, Filterkonvertern etc. nimmt genauso rapide ab wie die Verbreitung von PR-TNCs ;-) Wenn man Glück hat dann hat der eigenen TRX den Kram bereits eingebaut und man erspart sich HamRadioDelux oder FLDigi.

3. Ja es exisitiert ein Konzept. Dieses Konzept beschränkt sich aber ausschliesslichlich auf die bereits erwähnte Kommando-Ebene. Dies sind bei uns hier in die Bayern:
Staatsministerium des Inneren - Bezirksregierung - Kreisverwaltungsbehörde (Rathäuser und Landratsämter)
Details möchte ich hierzu noch nicht verbreiten, da die Konzepte im Distrik Franken derzeit im Aufbau sind und es hier auch um Technik geht.

4. Die Anforderungen der Bezirksregierungen sind recht simpel:
4a. Funkverkehr mit dem StMI - möglichst in Schriftform und per Email
4b. Funkverkehr mit den Kreisverwaltungsbehörden - Sprachform reicht vollkommen
4c. Wie die kreisverwaltungsbehörden zu ihren Infos kommen ist übrigens absolut zweitrangig. Im lokalen Bereich wird TETRA-DMO oder der gute alte 4/2m-Funk sicherlich gute Dienste tuen. Wenn gar nichts mehr geht reichen auch berittene Boten ;-)

5.
Die Anforderungen von Punkt 4 können ziemlich gut adhoc aus dem Stand heraus umgesetzt werden:
5a. Winlink Peer-to-Peer und Winlink RMS Verbindungen mit WINMOR oder (besser) PACTOR (mind. 2, besser 3)
5b. FM-Sprechfunkverkehr - entweder in Direktverbindungen oder (besser) über Notstromversorgte Relais
5c. Nicht unser Problem

Ich denke - jetzt kommen wir der Sache und dem Grund meines Threads hier auch näher, oder? ;-)

Ich stelle mir vor, einen PR-Datenfunkverkehr zwischen den Kreisverwaltungsbehörden der Bezirksregierung einzurichten.
Ich stelle mir vor, das dann eine Notfunkstelle am QTH der Bezirksregierung den Datenverkehr zwischen StMI und Regierung abwickelt - und den PR-Datenaustausch mit einbezieht - und quasi als Funkvermittlung arbeitet.

Klar ist dazu folgendes:
* Bei der Bezirksregierung sitzt im Einsatzfall ein Funkamateur.
* Im besten Fall sitzt bei jeder Kreisverwaltungsbehörde auch ein Funkamateur.
* Die HAM-OPs arbeiten dann im Schulterschluss mit den BOS-Funkern und unterstützenden Einheiten zusammen (z.B. KommFü, FüKomm, UGs etc pp) - damit niemand sich mit der Technik herumschlagen muss.
* Kein Verwaltungsbeamter muss/soll selbst Mikrofon oder Tastatur in die Hand nehmen, es sei denn man findet die Möglichkeit, problemlos Emails oder Faxe oder was weiss ich was zu verschicken, welche nicht-technisch orientierte Menschen nutzen können (z.B. PIGATE).

Mögliche Einsatzfälle?
Keine Frage: Immer dann, wenn die Struktur des TETRA-Digitalfunk bedroht und/oder betroffen ist. Dies ist beispielsweise der Fall bei großflächigen und lang anhaltenden Stromausfällen (bei denen garantiert keine Quatschfunker mehr zuhause vor den Geräten sitzen werden - die haben dann ganz andere Sorgen).

So, ich denke, ich habe den Rahmen abgesteckt, wofür ich ein Datenfunknetz als nützlich erachte. Zurück zur Technik:

RTTY ist ganz toll. Dreiviertel meiner alten QSL-Karten bestätigen, das ich früher ausschliesslich RTTY (mit Siemens T100s und DJ6HP Konverter) auf Kurzwelle gemacht habe. Ich weiss also worum es geht. Ich weiss aber auch, das RTTY NICHT GEEIGNET ist, den Anforderungen der Behörden (siehe Punkt 4a) zu genügen. Lieber würden die Verwaltungsbeamte mit Sprechfunk arbeiten, als das sie riskieren, das aus einer Verpflegungssanforderung für 300 evakuierte Personen eine Verpflegungssanforderung für 3000 - oder gar nur 30 Personen wird. Genau das kann mit RTTY und PSK aber jederzeit geschehen. Dann doch lieber in Sprechfunk - denn hierbei hat jeder ausgebildete BOS-Funker eine weitaus bessere Funkdisziplin und Betriebstechnik als 99% aller Funkamateuere zusammen (nicht böse und persönlich gemeint).

Aus diesem Grund ist auch der WINMOR/PACTOR-Link zwischen StMI und Bezierksregierungen von entscheidender Bedeutung - wobei WINMOR übrigens von aktiven Notfunkern als "nicht geeignet für Notfunk" eingestuft wird.

... und aus diesem Grunde denke ich über eine einfachzu realisierende und preisgünstige Lösung nach, wie man Daten zwischen Kreisverwaltungsbehörden und der Bezirksregierung auf UKW-Frequenzen transportieren kann.

Ich hoffe, das hat jetzt die meisten Fragen beantwortet.

73, Guido


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
[quote]... Ich weiss aber auch, das RTTY NICHT GEEIGNET ist, den Anforderungen der Behörden (siehe Punkt 4a) zu genügen. Lieber würden die Verwaltungsbeamte mit Sprechfunk arbeiten, als das sie riskieren, das aus einer Verpflegungssanforderung für 300 evakuierte Personen eine Verpflegungssanforderung für 3000 - oder gar nur 30 Personen wird. Genau das kann mit RTTY und PSK aber jederzeit geschehen. ..... [/quote]Dann kannst Du aber mit gleicher Begründung PR ebenfalls vergessen. Wenn Du alte H/W-Lösungen nicht willst, bleibt Dir nur der PC mit einer S/W-Lösung ....... und da liegt der Teufel im Detail. Das mag ja noch preisgünstig sein, aber wenn es eine sichere Verbindung sein soll, ist es nicht mehr einfach. Es wird leider zu oft unterschätzt, welcher Murks bei PR passieren kann.

Im übrigen: es ist doch logisch, daß es in's organisatorische abrutscht. Eine PTT kann jeder drücken und eine Tastatur bedienen noch ein hoher Prozentsatz. Im Notfall ist Organisation das A und O.
73 Peter


  
 
 Betreff des Beitrags: Re: 1K2 Packet Radio als Notfunk-Datenbübertragung
Hallo Guido,

dass war mehr als informativ. Danke!

Wie wäre denn PR, wenn man die Linkstrecken im DAMA-CSMA Betrieb aufbaut? Soweit ich mich da erinnern kann, kann man die Datendurchsatzrate damit deutlich erhöhen.

DAMA D(emand) A(ssigned) M(ultiple) A(ccess) = anforderungsbezogener Vielfachzugriff (auf den Übertragungskanal).

Die TNC der Teilnehmer werden vom Netzknoten gepollt (gerufen), d.h. sie gehen nur nach einer entsprechenden Aufforderung vom Netzknoten auf Sendung. Sie werden im Zuteilungsverfahren gleichberechtigt koordiniert. Es werden "rundherum" alle Stationen auf der Frequenz abgefragt und mit Datenpaketen "bedient", unabhängig ihrer HF-Leistung, ihren Parametern und ob sie sich gegenseitig hören (stören).


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum