@Anaximander dann gehen wir das telex log (denn genau das ist es, hat also erstmal mit acars recht wenig zu tun!) mal durch:
12:50:22 eine MED (ist mir jetzt auch nicht geläufig, was genau das ist) augenscheinlich vom flughafen BKK (BKK (airport) XC (abteilung) XA (firma), dürfte sich aber um einen telex-server handeln. geht an DPCCAMH (dpc ist kein IATA-code, sondern dürfte DEPARTURE CONTROL sein, CA ist MH OPS und dann MH für die airline). hat also direkt nichts mit MH370 zu tun, bezieht sich aber inhaltlich auf 9MMRO. ist definitiv niemals an die maschine geschickt worden! soll die bestätigung sein, dass eine VHF-verbindung aufgebaut wurde. so auch noch nie gesehen...
15:03:26 flugplan (warum auch immer Warning!?) aus dem server-protokoll (Incoming Uplink)
für FUEL EFFICIENCY route für MH370
15:03:36 eigentlicher ACARS-flugplan von DPCCAMH an den ACARS-server ACYFEXS (nicht aufschlüsselbare telex adresse des ACARS-servers), zur weiterleitung an die ACARS-adresse 3PDI2.21 (terminaladresse von 9MMRO) zu kosten MAS.
2x (1x Ground Sent, also die msg aus dem sendeprotokoll bei MH, 1x Routed, also aus dem ACARS-server log)
15:03:36 FMS flugplan (warum auch immer Warning!?) aus dem server-protokoll (Incoming Uplink) - sollte mit dem FE flugplan identisch sein und wird direkt in den flight computer eingespeist.
15:05:17 (neuer?) FUEL EFFICIENCY flugplan (müsste man mal vergleichen, wo da änderungen sind, ist mir aber auf die schnelle zu mühsam)
danach das ganze nochmal als ACARS flugplan GROUND SENT und ROUTED und als FMS flugplan (s.o.)
beide lang-pläne wieder markiert mit WARNING - könnte z.b. an der größe liegen, die so für ACARS auch recht ungewöhnlich ist.
15:54:29 wieder eine MED aus BKK, diesmal soll daraus hervorgehen, dass die SATCOM-verbindung verloren wurde. woran auch immer man das erkennen will... das alphanumerische kauderwelsch ergibt für außenstehende keinen sinn.
15:54:31 antwort von DPCCAMH an BKK als freetext message, VHF3 auf sprachübertragung frequenz 131.550 umzustellen, falls satcom funktioniert. das dann wieder als GROUND SENT (jetzt benannt UPLINK SENT) und ROUTED.
15:54:36 eine antwort von BKK, die hier als bestätigung für die erfolgreiche übertragung ausgegeben wird.
ab 15:54:41 geht das jetzt hin und her mit hergestellter SATCOM und verlorener VHF, interessanterweise aber jetzt nicht mehr von BKKXCXA sondern QXSXMXS. weshalb hier plötzlich eine andere adresse ins spiel kommt - ???
...
16:06:14 ACARS-loadsheet von KULKJMH (KUL ground ops von MH) und NOTOC (gefahrgut-information, wobei hier kein gefahrgut angegeben ist, sondern nur die verderbliche fracht (mangostane), für die eigentlich garkeine NOTOC ausgestellt werden muss). interessanterweise kein name des loadcontrollers (wäre hier in FRA unüblich), sondern nur die lizenznummer K8-45m gültig bis 20. September 2018 und der hinweis, dass eine NOTOC dazugehört.
ein ziemliches durcheinander von senderichtungen, mal von ground kommend, mal an ground rausgehend, dann wieder an ACARS rausgehende (UPLINK)... sehr unübersichtliche darstellung.
ab 16:06:32 folgen dann die angeblichen bestätigungen über die erfolgreiche zustellung, 1x von QXSXMXS, einmal von DPCCAMH an KULKJMH (und 1x deren ROUTING)
dann folgt der ganze loadsheet-bunch nochmal, diesmal ergänzt um die bitte an den piloten, den empfang mit "LS FINAL OK (lizenznummer) (ICAO-code des abflughafens)" zu bestätigen (war bei MH standardprozedere und auch bei uns in FRA üblich, wobei wir kein ACARS verwendeten, sondern uns die hardcopy im cockpit abzeichnen ließen).
16:09:28 schickt der pilot dann die gewünschte bestätigung (absender QXSMXS - dürfte also ein ACARS-server sein) an DPCCAMH (MAS OPS). (shahs lizenznummer dürfte somit 751 gewesen sein)
... so geht das geplänkel noch ellenlang weiter mit flight-reports, fuel-msgs, etc... springen wir mal zum interessanten teil:
18:03:23 die erste URGE(N)T REQUEST msg von MAS OPS DPCCAMH an 9MMRO via ACARS-server QXSXMXS.
der folgt um 18:03:24 die angebliche bestätigung (link ack), dass sie zugestellt wurde, dann aber um 18:06:25 plötzlich "UP INTERCEPT AIRCRAFT NOT LOGGED ON"
die msg geht dann 18:08:09 in den RETRANSMIT, der aber genauso fehlschlägt (trotz "link ack"), wie zuvor.
das gleiche erneut 18:10:00, 18:11:50, 18:13:40, 18:15:23, 18:17:11 (wobei ab eigentlich von einer neuen message auszugehen ist und kein automatischer re-transmit, weil diese wieder von DPCCAMH diesmal an BKKXCXA (telex serverm, nicht ACARS?!) geht, so auch der ret-transmit 18:18:14, bis sie dann 18:19:34 als TRASHED in die serverinterne runablage von BKKXCXA als nicht zustellbar wandert, worüber nun DPCCAMH informiert wird
18:38:51 bittet dann MAS OPS (diesmal gleich via BKKXCXA) um bestätigung der test-message (welche
test-message denn eigentlich????) und kopiert sich das auch gleich mal in einen lokalen ordner D:\output\FlightOperation\ODC\B777\07-03-2014.CSV , was im telexprotokoll als senden an CPYXXXX auftaucht (dummy-adresse).
auch diese msg geht mehrfach ins re-routing, wobei diesmal aber kein "link ack" mehr folgt (nicht via SATCOM?!) stattdessen direkt die KNO mit NO ACK.
ganz verrückt wird es um 23:00:42, als nochmal ein FE flugplan geschickt wird. da hat man seit stunden keinen kontakt mehr zum flieger, bekommt auf seine beiden messages keine antwort, (erreicht auch telefonisch niemanden an bord), aber schickt erstmal noch nen neuen flugplan, wobei der maschine inzwischen schon rein rechnerisch der sprit zur neige gehen müsste. verstehe, wer will...
insgesamt ist die darstellung in diesen logs super unübersichtlich, es fehlt eine deutliche erläuterung zu den adressen, die auch schon mal völlig ohne erklärung (s. 18:17) plötzlich mittendrin wechseln und auch, wie man z.b. aus den MED oder den späteren link ack msgs irgendeine information ziehen kann, bzw. was diese überhaupt beinhalten und wie sie zustande kommen. man hat seitens malaysia einfach mal wieder alles, dessen man habhaft werden konnte, und das für einen selbst erstmal unverfänglich ist, zusammengeklatscht und der öffentlichkeit zum fraß vorgeworfen (und auch den flugunfallermittlern, die auch nicht wirklich firm in kommunikations- und netzwerktechnik sind - ist ja auch nicht deren aufgabenfeld).
meine schlussfolgerung: BKKXCXA = telex und ACARS via VHF, QXSXMXS = ACARS via SATCOM - aber auch dies alles unter vorbehalt, weil ich da selbst nicht mehr so ganz durchsteige...
erste nachricht kam nicht durch und wurde schließlich getrashed mit dem response, dass 9MMRO nicht eingeloggt ist, die zweite bekam von vornherein stets die antwort, dass der empfang nicht bestätigt wurde.
somit ist definitv
keine nachricht durchgegangen - und tatsächlich hat man sogar direkt die negativ-bestätigung auch erhalten!
zu den telefonaten findet sich in diesem protokoll gar nichts.