SAP UND REMOTE-NETZZUGRIFF

Änderungsverlauf

Revision: Datum: Beschreibung
D05r01: 29. November 2011: Erstentwurf
D05r02: 30. November 2011: Leitartikel
D05r03: 20. Februar 2012: Leitartikel
D05r04: 27 März 2012: Änderungen nach CWG review
D05r05: 11. April 2012: Änderungen nach der 2. CWGview
D05r06: 22. Mai 2012: Änderungen nach BARB review
D05r07: 25. Mai 2012: Leitartikel CWG
D05r08: 25. Juni 2012: Weitere Leitartikel und Konsolidierung
D05r09: 04 Juli 2012: Änderungen nach Terrys Kommentaren
D05r10: 10. September 2012: Leitartikel
D05r11: 16. September 2012: Leitartikel
D05r12: 24. September 2012: Formatierung, Rechtschreibprüfung
Version 10: 23. Oktober 2012: Genehmigt vom Bluetooth SIG Board of Directors

Mitwirkende

Name: Unternehmen

Tim Howes: Accenture
Gerald Stöckl: Audi
Joachim Mertz:  Berner&Mattner
Stephan Schneider: BMW
Burch Seymour: Kontinental
Meshach Rajsingh: CSR
Stefan Hohl:  Daimler
Robert Hrabak:  GM
Alexej Polonski:  Jungo
Kyle Penri-Williams:  Papagei
Andreas Eberhardt:  Porsche
Thomas Frambach:  VW

1. Geltungsbereich

Der SIM Access Profile (SAP) ermöglicht einem Bluetooth-fähigen Gerät den Zugriff auf Daten, die auf der SIM-Karte eines anderen Bluetooth-fähigen Geräts gespeichert sind. In einem typischen Anwendungsfall ist ein Netzwerkzugriffsgerät (NAD) für ein Mobilfunknetz in ein Fahrzeug eingebaut, enthält aber keine SIM-Karte. Stattdessen wird eine SAP-Verbindung mit einem Mobiltelefon hergestellt. Das NAD verwendet die auf der SIM-Karte gespeicherten Sicherheitsanmeldeinformationen, um sich beim Mobilfunknetz anzumelden.
In diesem Fall fungiert das Mobiltelefon als SAP-Server, während das NAD das SAP-Client-Gerät ist. Auf alle Daten auf der SIM-Karte des Telefons, einschließlich Telefonbucheinträgen und SMS-bezogenen Daten, kann mithilfe von SAP-Befehlen zugegriffen werden. SAP ermöglicht Premium-Telefonie aus mehreren Gründen (siehe auch 2.1). Wenn das Mobiltelefon jedoch akzeptiert hat, als SAP-Server zu fungieren, kann es im Allgemeinen keine Mobilfunkdienste nutzen, und ein
Insbesondere die Internetverbindung. Die aktuellen Bluetooth-Spezifikationen beschreiben keine Methode, mit der ein Mobiltelefon parallel zu einer SAP-Sitzung eine Datenverbindung aufrechterhalten kann. Dies wirkt sich insbesondere auf die Akzeptanz von SAP im Smartphone-Markt aus, da diese Geräte einen permanenten Internetzugang benötigen.
In diesem Dokument werden Methoden und Empfehlungen zur Vermeidung dieser Verbindungsprobleme beschrieben.

2. Motivation

2.1 VORTEILE VON SAP

Für passende Car Kit Lösungen bietet das SIM Access Profile bietet eine Reihe von Vorteilen im Vergleich zum HFP Profile.

2.1.1 Geringe Akzeptanz von Gerätehalterungen bei den Verbrauchern

Mithilfe von Telefonhalterungen kann die Antenne1 des Mobiltelefons an eine externe Autoantenne angeschlossen werden.
Verbraucher empfinden Halterungen jedoch als unbequem und lästig und wünschen sich ein nahtloses und müheloses Erlebnis. Beim Einsteigen ins Auto möchte der Kunde das Telefon in der Tasche lassen und es nicht herausnehmen müssen, um es in eine Halterung zu legen. Vorausgesetzt, der Benutzer schließt ein Telefon erfolgreich über eine Halterung an, besteht dadurch das Risiko, dass er das Telefon beim Verlassen des Autos vergisst.
Das nächste Akzeptanzproblem bei Halterungen ist die Skalierbarkeit der Geräte. Der Kunde muss eine neue Halterung kaufen, wenn er sein Telefon austauscht. Häufig sind neue Halterungen nicht sofort nach der Markteinführung neuer Geräte verfügbar, und für viele Telefone sind Halterungen überhaupt nicht verfügbar. Dies schränkt die Auswahl an verfügbaren Geräten für den Benutzer ein.
Daher ist die Marktakzeptanz von Cradles heute sehr eingeschränkt. Bei der Verwendung von SAP ist kein Consumer Device Cradle erforderlich.

2.1.2 ERWEITERTE TELEFONIEFUNKTIONEN

Die erweiterten Telefoniefunktionen von SAP ermöglichen es dem Kunden, wichtige anrufbezogene Telefoniefunktionen während der Fahrt zu ändern oder dem Kunden detailliertere Informationen bereitzustellen. In vielen Ländern verbieten die Behörden die Nutzung von Verbrauchergeräten während der Fahrt. Die einzige legale Möglichkeit, mit dem Verbrauchergerät zu interagieren, ist die Infotainment-Benutzeroberfläche des Fahrzeugs.
ExampDie in SAP verfügbaren Telefoniefunktionen sind

• Anrufer-ID: aktivieren, deaktivieren, aktuellen Status abfragen
• Anrufweiterleitung: aktivieren, deaktivieren, ändern
• Manuelle vs. automatische Netzwerkauswahl: ändern
• (De-)Aktivieren Sie „Roaming erlaubt“ für den Datentransfer über die SIM
• Zeigen Sie den Namen des Dienstanbieters anstelle des Namens des Netzbetreibers an.

Denn die HFP Profile bietet keinen Zugriff auf diese Telefonie-Funktionen, SAP ist der einzige Profifile um diese Anwendungsfälle für Fahrer zu ermöglichen.

2.1.3 OPTIMIERTE NETZABDECKUNG

Eine deutliche Verbesserung hinsichtlich der Netzabdeckung bietet SAP:

• Bei Verwendung von SAP nutzen die Telefonfunktionen des Fahrzeugs den im Fahrzeug integrierten NAD, der eine direkte Verbindung zur externen Mobilfunkantenne herstellt. Dies führt zu einer verbesserten Signalqualität und einer optimierten Netzabdeckung, wodurch die Anzahl der Signalverluste verringert wird.
• Dieser Vorteil wird noch deutlich erhöht, wenn das Auto mit metallisierten Fenstern ausgestattet ist, die den Energieverbrauch des Autos für die Klimaanlage senken. Signalverluste von etwa 20 dB sind bei der Verwendung der eingebauten Antenne eines Mobiltelefons in einem solchen Auto üblich. Dieses verschlechterte Signal kann zu Netzwerkverlusten, schlechtem Empfang und deutlich niedrigeren Datenübertragungsraten führen.
• Wenn der Benutzer eine Telefonhalterung in seinem Auto hat, kann die Antennenkopplung die Übertragungsqualität beeinträchtigen, wenn diese Kopplung induktiv erfolgt. Typische induktive Kopplungsverluste liegen im Bereich von 6 bis 10 dB.

2.1.4 NIEDRIGE KOMPLEXITÄT VON SAP

Da SAP auf etablierte 3GPP-Standards verweist (Verwendung des APDU-Formats) und nur eine sehr einfache Implementierung eines Zugriffsmechanismus auf die SIM-Karte erfordert, ist die Anzahl potenzieller Interoperabilitätsprobleme beim Betrieb von SAP im Vergleich zu HFP-Implementierungen gering.

2.1.5 WENIGER ELEKTROMAGNETISCHE BELASTUNG FÜR KUNDEN

Im SAP-Betrieb sendet der NAD des Mobiltelefons nicht. Dadurch wird die elektromagnetische Belastung des Fahrers minimiert. Ohne SAP muss die Sendeleistung des Telefons aufgrund der Abschirmwirkung der Karosserie erhöht werden. Zudem erhöht sich die Akkulaufzeit des Mobiltelefons.

2.1.6 MWS-KOEXISTENZ

Die Koexistenz von Bluetooth mit anderen drahtlosen Technologien, insbesondere 4G-Netzwerken wie LTE, könnte in naher Zukunft zu einem kritischen Thema werden und wird daher in der Bluetooth SIG intensiv diskutiert (Mobile Wireless Coexistence Issue; siehe auch [5]). SAP kann erheblich dazu beitragen, solche Probleme zu vermeiden, da NAD eine externe Mobilfunkantenne mit einem wesentlich besseren Antennenabstand als das Mobilteil verwendet.

2.2 Anwendungsfälle

In diesem Abschnitt werden einige relevante Anwendungsfälle beschrieben, die in diesem Whitepaper behandelt werden.

1. . Internet Zugang
   * Allgemeiner Anwendungsfall: Internetanwendungen Mobile Geräte wie Smartphones benötigen für eine Vielzahl von Anwendungen wie das Surfen im Internet, soziale Netzwerke, Blogs, Chats oder Newsfeeds einen häufigen oder permanenten Internetzugang.
   *Besonderer Anwendungsfall: E-Mails über MAP Mobile Nachrichten per E-Mail sind zu einer wichtigen Anwendung der Bluetooth-Technologie im Auto geworden. Bluetooth hat diesen Anwendungsfall durch die Entwicklung des Message Access Pro abgedeckt.file (MAP, [1]). Allerdings ermöglicht MAP dem Car Kit, als Mail-Client des Mobiltelefons zu fungieren. Es bietet keine Möglichkeit, auf der MAP-Client-Seite E-Mails zu senden/empfangen.
   * Spezieller Anwendungsfall: Personal Information Management Die Bluetooth SIG entwickelt derzeit einen Profile Zugriff auf die Kalenderdaten auf dem Mobiltelefon ermöglichen. Da Kalendereinträge normalerweise über IP-Netzwerke übermittelt werden, würde ein Verlust der IP-Verbindung auch diesen Anwendungsfall beeinträchtigen. Daher sollte ein in SAP betriebenes Mobiltelefon in der Lage sein, solche Kalendereinträge zu senden und zu empfangen.
2. Direct Mail
   Mobiles Messaging per SMS ist nach wie vor ein wichtiger Markt. Dementsprechend sollte das Versenden von SMS auch für ein mit SAP betriebenes Mobiltelefon möglich sein.
3. Nur Stimme
   Der SAP-Profifile stammt aus dem Jahr 2000 und konzentriert sich daher auf Sprachtelefonie. Smartphones, die eine ständige Internetverbindung benötigen, kamen nicht in Frage. Die Verwendung von SAP nur für Sprachtelefonie ist jedoch nach wie vor ein gültiger Anwendungsfall. Der reine Sprachanwendungsfall wird durch die vorhandene Spezifikation abgedeckt und sollte keine Änderungen erfordern.

3. Lösungen

3.1 ÜBERVIEW

In den folgenden Abschnitten werden die Lösungen beschrieben, die zur Behebung der in Abschnitt 2 beschriebenen Probleme angewendet werden können:

1. Internet Zugang:
   Ein Mobiltelefon oder ein anderes mobiles Gerät, das als SAP-Server fungiert, muss für den Zugriff auf das Internet aktiviert werden.
2. SMS-Übertragung:
   Ein Mobiltelefon oder ein anderes mobiles Gerät, das als SAP-Server fungiert, muss zum Senden und Empfangen von SMS-Nachrichten aktiviert sein.
3. Nur Stimme:
   SAP wird nur für die Sprachtelefonie verwendet.

Generell gilt, dass die in den folgenden Abschnitten beschriebenen Lösungen für den Anwender möglichst transparent sein sollen; es sollte ihm egal sein, ob er SAP oder HFP im Einsatz hat.
Darüber hinaus bleibt das SAP-Server-Gerät die zentrale Einheit für die Kommunikation; beispielsweise sollten die Historien eingehender und ausgehender Kommunikationstransaktionen, wie gesendete oder empfangene Nachrichten, weiterhin auf dem SAP-Server verfügbar sein.
Der Umgang mit MMS im SAP-Betrieb wird in diesem Whitepaper nicht explizit beschrieben. Da MMS jedoch sowohl den Empfang von SMS als auch eine IP-Verbindung zum MMS-Server erfordert, wird die Problematik implizit durch die Anwendungsfälle SMS-Transfer und Internet-Zugriff abgedeckt.

3.2 INTERNETZUGANG

3.2.1 ALLGEMEINER ANWENDUNGSFALL INTERNETZUGANG

Objektiv:
Gewähren Sie dem SAP-Servergerät Zugriff auf das Remote-IP-Netzwerk, während SAP aktiv ist. Beschreibung:
Das SAP-Server-Gerät (z. B. ein Mobiltelefon oder ein Smartphone) hat dem SAP-Client-Gerät (z. B. einem Car Kit oder einem Tablet-Computer) Zugriff auf seine SIM-Daten gewährt und der SAP-Client hat diese Daten zur Authentifizierung gegenüber dem Mobilfunknetz verwendet. Der SAP-Server hat demnach keinen Zugriff auf das Mobilfunknetz, während der SAP-Client sein eigenes Netzwerkzugriffsgerät (NAD) verwendet, um mit dem Mobilfunknetz zu kommunizieren.
Um dem SAP-Server Internetzugriff zu ermöglichen, muss das SAP-Client-Gerät als Netzwerkzugriffspunkt für den SAP-Server fungieren. Dazu muss eine IP-Verbindung zwischen dem SAP-Server und den SAP-Client-Geräten hergestellt werden.
Die hier beschriebene Lösung verwendet das Bluetooth BNEP Protokoll für die IP-Verbindung zwischen den beiden SAP Geräten und das PAN profile um den Netzwerkzugangspunkt bereitzustellen. Beachten Sie, dass möglicherweise auch andere Lösungen möglich sind, z. B. eine IP-Verbindung über WLAN.
Für die hier definierte Lösung müssen folgende Voraussetzungen erfüllt sein:

• Zwischen den beiden Geräten ist eine SAP-Verbindung hergestellt.
• Das SAP-Server-Gerät muss die PANU (PAN-User)-Rolle des PAN pro unterstützenfile [3].
• Das SAP-Client-Gerät muss die NAP-Rolle (Network Access Point) des PAN pro unterstützenfile.

Abbildung 1 zeigt den Verbindungsaufbau, um dem SAP-Server den Zugriff auf das externe IP-Netzwerk zu ermöglichen:

Abbildung 1: Ablauf des Verbindungsaufbaus PAN/BNEP

1. Wenn die SAP-Verbindung zwischen den beiden Geräten hergestellt ist und eine Anwendung auf dem SAP-Server-Gerät eine IP-Verbindung zum Remote-Netzwerk erfordert, richtet das SAP-Server-Gerät (PANU-Rolle) eine PAN/BNEP-Verbindung zum SAP-Client (PAN-NAP-Rolle) ein. Normalerweise erfordert dieser PAN-Verbindungsaufbau keine Benutzerinteraktion.
2. Der BNEP-Verbindungsaufbau sollte die Übertragung von Access Point Name Data (APN) oder eine Auswahl vordefinierter APNs auf der SAP-Client-Geräteseite umfassen, wie in [4] definiert.
3. Nach dem erfolgreichen Aufbau der PAN/BNEP-Verbindung wird die IP-AdressetagRAMs können automatisch zwischen dem SAP-Servergerät und dem Remote-Netzwerk übertragen werden, wobei das SAP-Clientgerät als Router für das Remote-IP-Netzwerk fungiert.
4. Es können mehrere PAN/BNEP-Verbindungen wie oben beschrieben aufgebaut werden, um beispielsweise mehrere Zugangspunkte in der Infrastruktur des Mobilfunknetzes anzusprechen.

In den folgenden Abschnitten wird die Verwendung des oben genannten allgemeinen Mechanismus für einige spezifische Anwendungen beschrieben.

3.2.2 SPEZIELLES ANWENDUNGSSZENARIO: E-MAIL-ZUGRIFF ÜBER KARTE

Objektiv:
Aktivieren Sie ein SAP-Servergerät zum Senden und Empfangen von E-Mails, während SAP aktiv ist.
Beschreibung:
Eine spezielle Anwendung für den oben beschriebenen Internet-Zugriffsmechanismus ist die Übertragung von E-Mails mit Hilfe des Message Access Profile [1].

Für eine MAP-Sitzung mit SAP-Betrieb müssen folgende Voraussetzungen erfüllt sein:

• Es gelten die allgemeinen Voraussetzungen für den Internetzugang wie in Abschnitt 3.2 beschrieben.
• Das SAP-Servergerät fungiert als MAP Server Equipment (MSE) und der SAP-Client fungiert als MAP Client Equipment (MCE).
• Sowohl MSE als auch MCE unterstützen die MAP-Funktionen „Nachrichten durchsuchen“, „Nachrichten hochladen“, „Nachrichtenbenachrichtigung“ und „Benachrichtigungsregistrierung“.

Abbildung 2 beschreibt die Abläufe und die Nutzung der MAP-Funktionen für einen E-Mail-Empfang:

Abbildung 2: Ablauf eines E-Mail Empfangs im MAP mit SAP Betrieb

1. Die MAP MSE- und MCE-Geräte haben eine „Message Access Service“-Verbindung und eine „Message Notification Service“-Verbindung hergestellt.
2. Das SAP-Servergerät (als PANU) hat eine PAN/BNEP-Verbindung zum SAP-Clientgerät (als PAN-NAP) hergestellt.
3. Die MSE ruft die E-Mail mithilfe der PAN/BNEP-Verbindung über den NAD der MCE aus dem Netzwerk ab.
4. Die MSE sendet eine „NewMessage“-Benachrichtigung an den MCE, um anzuzeigen, dass eine neue Nachricht empfangen wurde.
5. Der MCE kann die Nachricht durch eine „GetMessage“-Anforderung abrufen.

Siehe auch [1] für Beschreibungen der MAP-Funktionen „SendEvent“ und „GetMessage“.

Abbildung 3 beschreibt die Abläufe und die Nutzung der MAP-Funktionen zum Versenden einer E-Mail:

Abbildung 3: Ablauf beim E-Mail-Versand im MAP mit SAP-Bedienung

1. Die MAP MSE- und MCE-Geräte haben eine „Message Access Service“-Verbindung und eine „Message Notification Service“-Verbindung hergestellt.
2. Das SAP-Servergerät (als PANU) hat eine PAN/BNEP-Verbindung zum SAP-Clientgerät (als PAN-NAP) hergestellt.
3. Wenn die Nachricht auf dem MCE-Gerät erstellt wird, schiebt der MAS-Client des MCE die Nachricht in den Ordner „Postausgang“ des MSE. Wenn die Nachricht auf dem MSE-Gerät erstellt und zum Senden bereit ist, wird die Nachricht in den Postausgangsordner gelegt oder aus dem Entwurfsordner verschoben.
4. Wenn die Nachricht in den Ordner „Postausgang“ verschoben wurde, sendet die MSE eine „NewMessage“-Benachrichtigung an den MCE, die signalisiert, dass die Nachricht akzeptiert wurde. Wenn eine Nachricht erstellt oder in den Ordner „Postausgang“ auf der MSE verschoben wurde, sendet die MSE ein „MessageShift“-Ereignis.
5. Die MSE sendet die Nachricht über ihre PAN/BNEP-Verbindung an das Netzwerk.
6. Wenn die Nachricht erfolgreich an das Netzwerk gesendet wurde, verschiebt die MSE die Nachricht vom Postausgang in den Ordner „Gesendet“ und benachrichtigt den MCE entsprechend.

Siehe auch [1] zur Beschreibung der MAP-Funktionen „SendEvent“ und „PushMessage“.

3.2.3 SPEZIELLES ANWENDUNGSSZENARI: ZUGRIFF AUF KALENDERDATEN

Objektiv:
Aktivieren Sie ein SAP-Servergerät, um Kalenderdaten zu senden und zu empfangen, während SAP aktiv ist.
Beschreibung:
Eine weitere spezifische Anwendung für den beschriebenen Internet-Zugangsmechanismus (3.2.1) ist die Übertragung von Kalenderdateneinträgen über ein IP-Netzwerk. Die Entwicklung eines Kalenderprogrammsfile ist zum Zeitpunkt der Erstellung dieses Whitepapers in Arbeit, daher sind noch keine detaillierten Funktionen definiert.
Daher wird nachfolgend nur ein Entwurf der erforderlichen Aktionen angegeben. Im Allgemeinen ähneln die Anforderungen für diesen Anwendungsfall den Anforderungen für den E-Mail-Zugriff (siehe 3.2.2).

Abbildung 4: Schematischer Ablauf zum Empfang von Kalenderdaten im SAP-Betrieb

Abbildung 5: Schematischer Ablauf zum Versenden von Kalenderdaten im SAP-Betrieb

3.3 Anwendungsfall SMS-Zugriff

3.3.1 ÜBERVIEW

Objektiv:
Beschreiben Sie die Mechanismen für ein SAP-Servergerät zum Senden und Empfangen von SMS, während SAP aktiv ist.
Beschreibung:
Das SAP-Server-Gerät (z. B. ein Mobiltelefon oder ein Smartphone) hat dem SAP-Client-Gerät (z. B. einem Car Kit oder einem Tablet-Computer) Zugriff auf seine SIM-Daten gewährt und der SAP-Client hat diese Daten zur Authentifizierung gegenüber dem Mobilfunknetz verwendet. Dadurch ist der SAP-Server nicht mehr in der Lage, SMS-Nachrichten direkt zu senden oder zu empfangen.
Um einem Benutzer das Senden und Empfangen von SMS-Nachrichten zu ermöglichen, werden nachfolgend zwei Vorgehensweisen beschrieben:

• Eine einfache, ausschließlich auf SAP basierende Lösung
• Ein komplexerer, aber gründlicherer Ansatz basierend auf MAP

3.3.2 SMS-ZUGRIFF NUR MIT SAP

SMS erhalten:
Beim Betrieb im SAP-Modus empfängt das NAD des SAP-Clients eine SMS_DELIVER PDU oder SMS_STATUSREPORT PDU wie in 3GPP 23.040 definiert über den Mobilfunkprotokollstapel des NAD. Abhängig von den in 3GPP 23.040 und 3GPP 23.038 definierten Regeln für die vom NAD empfangene SMS-PDU kann das SAP-Client-Gerät die SMS dann auf der (U) SIM des SAP-Server-Geräts speichern. Dazu verwendet es das SAP APDU-Format, um die Speicherung der PDU über die SAP-Verbindung auf der (U) SIM im Elementarfeld EF[SMS] der (U) SIM anzufordern (die Definition des Felds finden Sie in 3GPP 51.011 v4 Kapitel 10.5.3). Dabei wird das Aktualisierungsverfahren gemäß 3GPP 51.011 Kapitel 11.5.2 und 3GPP 31.101 durchgeführt.
Senden Sie eine SMS:
Die SMS_SUBMIT PDU (siehe 3GPP 23.040) wird über den Protokollstapel des Mobilfunknetzes des NAD gesendet. Nach dem Senden kann der NAD die SMS, abhängig von den in 3GPP 23.040 und 3GPP 23.038 für die SMS PDU definierten Regeln, auf der (U) SIM speichern. Auch hier verwendet er das SAP APDU-Format, um die Speicherung der PDU anzufordern, und verwendet das Aktualisierungsverfahren gemäß 3GPP 51.011 Kapitel 11.5.2 und 3GPP 31.101.

Vorteiltages

• Die 3GPP-Anforderungen für Mobilfunknetze werden vollständig erfüllt.
• SMS werden nichtflüchtig auf dem (U)SIM-Speicher im Mobiltelefon gespeichert.
• Geringere Komplexität im Vergleich zur Lösung „Voller SMS-Zugriff“ aus Abschnitt 3.3.3, da keine zusätzlichen Kosten entstehen.file erforderlich. Somit ist diese Lösung auch für einfache Geräte geeignet.

Nachteiltages

• Bei Mobiltelefonimplementierungen kann es vorkommen, dass die (U) SIM EF[SMS] ignoriert wird, so dass der Kunde nach Beendigung der SAP-Verbindung unter Umständen nicht mehr in der Lage ist, über die Benutzeroberfläche seines Mobiltelefons auf die gesendeten bzw. empfangenen SMS zuzugreifen.
• Da das Telefon während des SAP-Betriebs keinen Zugriff auf die SIM-Karte hat, werden die Nachrichten während des SAP-Betriebs nicht auf dem Telefon angezeigt.
• Keine Auslösung des SMS-Versandes über das Mobiltelefon möglich.

3.3.3 VOLLSTÄNDIGER SMS-ZUGRIFF ÜBER KARTE

Der Hauptzweck des hier beschriebenen Ansatzes besteht darin, das SAP-Servergerät immer in die SMS-Kommunikation einzubeziehen. Dadurch wird sichergestellt, dass der SMS-Zugriff für den Benutzer vollständig transparent ist, da sich alle Historien gesendeter und empfangener SMS-Nachrichten im Nachrichtenspeicher des SAP-Servergeräts befinden.
Dazu werden die vom Remote-Netzwerk empfangenen SMS-PDUs automatisch vom NAD des SAP-Clients an den SAP-Client und umgekehrt übertragen, um sie unter Verwendung der OBEX-Funktionen des Message Access Pro zu versenden.fileFür diese Lösung müssen folgende Voraussetzungen erfüllt sein:

• Zwischen den beiden Geräten ist eine SAP-Verbindung hergestellt.
• Das SAP-Servergerät fungiert als MAP Server Equipment (MSE) und das SAP-Clientgerät fungiert als MAP Client Equipment (MCE).
• Sowohl MSE als auch MCE unterstützen die MAP-Funktionen „Nachrichten durchsuchen“, „Nachrichten hochladen“, „Nachrichtenbenachrichtigung“ und „Benachrichtigungsregistrierung“.
• Die beiden Geräte haben eine „Message Access Service“-Verbindung (MAS) und eine „Message Notification Service“-Verbindung (MNS) hergestellt.

Abbildung 6 beschreibt die Abläufe und die Nutzung der MAP-Funktionen für einen SMS-Empfang:

Abbildung 6: Ablauf eines SMS Empfangs durch Nutzung von MAP im SAP Betrieb

1. Der SAP-Client/MCE empfängt die SMS über seinen NAD vom Netzwerk.
2. Der MAS-Client des MCE überträgt die SMS-PDU oder – im Fall einer verknüpften SMS – die SMS-PDUs im nativen SMS-PDU-Format in den Ordner „Posteingang“ des MSE.
3. Wenn die SMS für den Benutzer bestimmt ist (also keine SMS der Klasse 2 ist), sendet die MSE eine „NewMessage“-Benachrichtigung an die MCE, die signalisiert, dass eine neue SMS empfangen wurde.

Abbildung 7 beschreibt den Ablauf und die Nutzung der MAP-Funktionen zum Versenden einer SMS:

1. Wenn die SMS auf dem SAP-Client/MCE-Gerät erstellt wird, schiebt der MAS-Client des MCE die SMS in den Ordner „Postausgang“ des MSE. Die SMS wird vom MSE in das SMS-Submit-PDU-Format transkodiert, wenn sie im Textformat gepusht wurde. Wenn die SMS auf dem MSE-Gerät erstellt wird und zum Senden bereit ist, wird die Nachricht in den Ordner „Postausgang“ gelegt oder aus dem Entwurfsordner verschoben.
2. Der MCE ruft die SMS-Submit-PDU mithilfe einer „GetMessage“-Anforderung aus dem „Postausgang“-Ordner des MSE ab und sendet sie an das Netzwerk.
3. Nach erfolgreichem Senden an das Netzwerk setzt der MCE den Status der Nachricht auf „gesendet“.
4. Die MSE verschiebt die Nachricht vom Postausgang in den Ordner „Gesendet“ und benachrichtigt den MC entsprechend.

Vorteiltages:

• Qualifizierbare Lösung.
• Im SAP-Betrieb werden SMS zurück an das Telefon übermittelt.

Nachteiltages:

• Für eine komplexe Implementierung müssen sowohl MAP als auch SAP auf beiden Geräten implementiert sein.
• Erfordert, dass sowohl MAP als auch SAP verbunden und gleichzeitig ausgeführt werden, damit keine SMS verloren gehen.
• Da das Telefon während des SAP-Betriebs möglicherweise keinen Zugriff auf die SIM-Karte hat, werden die Nachrichten während des SAP-Betriebs möglicherweise nicht auf dem Telefon angezeigt.

3.4 Anwendungsfall: Nur SAP-Telefonie

Zwischen einem SAP-Server und einem SAP-Client kann eine SAP-Verbindung aufgebaut werden, deren einziger Zweck es ist, Sprachtelefonie in bester Qualität bereitzustellen. In diesem Fall müssen keine weiteren für SAP definierten Anforderungen beachtet werden.

4. Abkürzungen

Abkürzung oder Akronym:  Bedeutung

3GPP:  Partnerschaftsprojekt der 3. Generation
BNEP:  Bluetooth-Netzwerkkapselungsprotokoll
GSM:  Globales System für Mobilkommunikation
HFP:  Freisprecheinrichtung Profile
IP-Adresse:  Internetprotokoll
MAS:  Nachrichtenzugriffsdienst
KARTE:  Nachrichtenzugriffs-Profile
MCE:  Nachricht an den Client
MMS:  Multimedia-Nachrichtendienst
MNS:  Nachrichtenbenachrichtigungsdienst
MSE:  Nachrichtenserverausrüstung
MWS:  Mobile drahtlose Koexistenz
NAD:  Netzwerkzugriffsgerät
SCHWENKEN:  Persönlicher Networking-Profifile
PDUs:  Protokolldateneinheit
SAP:  SIM Access Profile
SIM-Karte:  Teilnehmeridentitätsmodul
SMS:  Kurznachrichtendienst

5. Referenzen

1. Nachrichtenzugriffs-Profile 1.0
2. SIM Access Profile 1.0
3. Persönlicher Networking-Profifile (PAN) 1.0
4. Bluetooth Network Encapsulation Protocol (BNEP), Version 1.2 oder höher
5. MWS-Koexistenz-Logikschnittstelle, Bluetooth-Kernspezifikations-Nachtrag 3, Rev. 2

 

Bedienungsanleitung für SAP und Remote-Netzwerkzugriff – Optimiertes PDF
Bedienungsanleitung für SAP und Remote-Netzwerkzugriff – Original-PDF

Verweise

• Bedienungsanleitung