SAP KAJ RIMOTA RETA ALIRO

Historio de Revizio

Revizio: Dato: Priskribo
D05r01: 29 novembro 2011: Komenca Malneto
D05r02: 30 novembro 2011: Eldonejoj
D05r03: 20 februaro 2012: Eldonejoj
D05r04: 27 marto 2012: Ŝanĝoj post CWG review
D05r05: 11 aprilo 2012: Ŝanĝoj post 2a CWG review
D05r06: 22 majo 2012: Ŝanĝoj post BARB review
D05r07: 25 majo 2012: Ĉefartikoloj CWG
D05r08: 25 junio 2012: Pliaj ĉefartikoloj kaj firmiĝo
D05r09: 04 julio 2012: Ŝanĝoj post la komentoj de Terry
D05r10: 10 septembro 2012: Eldonejoj
D05r11: 16 septembro 2012: Eldonejoj
D05r12: 24 septembro 2012: Formato, literumkontrolo
V10: 23 oktobro 2012: Aprobita de la Estraro de Bluetooth SIG

Kontribuantoj

Nomo: Kompanio

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

1. Amplekso

La SIM Access Profile (SAP) permesas al Bluetooth-ebligita aparato aliri datumojn enhavitajn en la SIM-karto de alia Bluetooth-ebligita aparato. En tipa uzokazo retalira aparato (NAD) por ĉela reto estas enkonstruita en veturilo, sed ne enhavas SIM-karton. Anstataŭe SAP-konekto fariĝos per poŝtelefono. La NAD uzos la sekurecajn akreditaĵojn konservitajn en la SIM-karto por registriĝi ĉe la ĉela reto.
Ĉi-kaze la portebla telefono funkcias kiel SAP-servilo dum la NAD estas la SAP-klienta aparato. Ĉiuj datumoj enhavitaj en la SIM-karto de la telefono, inkluzive enirojn de telefona libro kaj datumoj pri SMS, estas alireblaj per komandoj de SAP. SAP ebligas altkvalitan telefonadon pro pluraj kialoj (vidu ankaŭ 2.1). Tamen, kiam la poŝtelefono akceptos funkcii kiel SAP-servilo, ĝi ne povos akiri ĉelajn retajn servojn ĝenerale, kaj
Interreta konekto precipe. Aktualaj Bluetooth-specifoj ne priskribas metodon por poŝtelefono konservi datuman konekton paralele kun SAP-sesio. Ĉi tio influas la akcepton de SAP precipe en la inteligenta telefono, ĉar ĉi tiuj aparatoj bezonas konstantan interretan aliron.
Ĉi tiu artikolo priskribas metodojn kaj rekomendojn por eviti ĉi tiujn konektajn problemojn.

2. Instigo

2.1 AVANTOJ DE SAP

Por taŭgaj aŭtomobilaj solvoj la SIM Access Profile provizas kelkajn avantaĝojn kompare kun la HFP Profile.

2.1.1 MALALTA AKCEPTO DE APARILOJ DE KONSUMANTO

Telefonaj luliloj povas esti uzataj por kunligi la antenon1 de la poŝtelefono al ekstera aŭta anteno.
Tamen konsumantoj perceptas lulilojn kiel maloportunajn kaj maloportunajn, kaj deziras sperton perfektan kaj senpenan. Enirante la aŭton, la kliento volas lasi la telefonon en poŝon aŭ sakon kaj ne esti devigita eltiri ĝin por meti ĝin en lulilon. Supozante, ke la uzanto sukcese konektas telefonon per lulilo, tio aldonas la riskon forgesi la telefonon forlasante la aŭton.
La sekva akcepta problemo por luliloj estas aparata skaleblo. La kliento devas aĉeti novan lulilon kiam li interŝanĝas sian telefonon. Ofte novaj luliloj ne haveblas tuj post merkata liberigo de novaj aparatoj, kaj por multaj telefonoj luliloj tute ne haveblas. Ĉi tio limigas la disponeblajn aparatajn elektojn por la uzanto.
Tiel, hodiaŭ la ĝenerala merkata akcepto de luliloj estas tre limigita. Kiam vi uzas SAP, ne necesas lulilo por konsumanto

2.1.2 Plibonigitaj TELEFONOJ

La plibonigitaj telefonaj trajtoj de SAP ebligas al la kliento modifi gravajn telefon-rilatajn telefonajn funkciojn dum la veturado aŭ provizi al la kliento pli detalajn informojn. En multaj landoj juraj aŭtoritatoj malpermesas la uzadon de la konsumanta aparato dum veturado; la interfaco de uzado de infotainment de la aŭto estas la sola laŭleĝa maniero interagi kun la konsumanta aparato.
Exampiuj telefonaj trajtoj haveblaj en SAP estas

• Identigilo de alvokanto: aktivigi, malaktivigi, peti aktualan staton
• Alvokosendado: aktivigi, malaktivigi, modifi
• Manlibro kontraŭ aŭtomata retelekto: modifi
• (De-) Aktivigu "Vagado permesita" por transdono de datumoj per la SIM
• Montru la nomon de la provizanto de la servo anstataŭ la nomo de la retfunkciigisto.

Ĉar la HFP Profile ne provizas aliron al tiuj telefonaj funkcioj, SAP estas la sola profesiulofile ebligi ĉi tiujn uzokazojn por ŝoforoj.

2.1.3 OPTIMIZITA RETA KUVERTADO

SAP provizas signifan plibonigon rilate al kovrado de reto:

• Kiam vi uzas SAP, la telefonaj trajtoj de la aŭto uzas la enkonstruitan NAD de la aŭto, kiu establas rektan ligon al la ekstera ĉela anteno. Ĉi tio rezultigas plibonigitan signalan kvaliton kaj optimumigitan retan kovradon, reduktante la nombron de signalaj perdoj.
• Ĉi tiu avantaĝo draste pliiĝas kiam la aŭto estas ekipita per metaligitaj fenestroj, kiuj estas uzataj por redukti la energian konsumon de la aŭto por klimatizilo. Signalaj perdoj de ĉirkaŭ 20 dB oftas dum uzado de enkonstruita anteno de poŝtelefono ene de tia aŭto. Ĉi tiu degradita signalo povas kaŭzi retan perdon, malbonan ricevon kaj signife malpli altajn datumajn translokigajn rapidojn.
• Se la uzanto havas telefonan lulilon en sia aŭto, la anteno-kuplado povas redukti la transdonan kvaliton kiam ĉi tiu kuplado realiĝas indukte. Tipaj induktaj kunligaj perdoj estas inter 6 kaj 10 dB.

2.1.4 MALALTA KOMPLEXECO DE SAP

Ĉar SAP rilatas al bone establitaj 3GPP-normoj (uzado de APDU-formato) kaj postulas nur tre simplan efektivigon de alira mekanismo al la SIM-karto, la nombro da eblaj kunfunkcieblecaj problemoj dum funkciigado de SAP estas malalta kompare kun HFP-efektivigoj.

2.1.5 MALMULA ELEKTROMAGNETIKA EKSPOXO POR KLIENTO

Kiam SAP funkcias, la NAD de la poŝtelefono ne elsendos. Tial, la elektromagneta ekspozicio de la ŝoforo povas esti minimumigita. Sen SAP, la transdona potenco de la telefono devas esti pli alta pro la ŝirmaj efikoj de la karoserio. Aldone pligrandiĝas la bateria vivo de la poŝtelefono.

2.1.6 MWS-KUNVIVO

La kunekzistado de Bluetooth kun aliaj sendrataj teknologioj, precipe 4G-retoj kiel LTE, povas fariĝi kritika afero en proksima estonteco kaj tial estas intense diskutita en la Bluetooth SIG (numero de Mobile Wireless Coexistence; vidu ankaŭ [5]). SAP povas signife kontribui por eviti tiajn problemojn, ĉar la NAD uzos eksteran ĉelan antenon kun multe pli bona anteno-disiĝo ol la telefono.

2.2 UZKAZOJ

Ĉi tiu sekcio priskribas iujn rilatajn uzokazojn, kiujn traktas ĉi tiu blanka libro.

1. . Interreta atingo
   * Ĝenerala uzokazo: Interretaj programoj Poŝtelefonaj aparatoj kiel poŝtelefonoj postulas oftan aŭ konstantan retaliron por diversaj aplikoj kiel interreta retumado, sociaj retoj, blogoj, retbabiloj aŭ novaĵoj.
   * Speciala uzokazo: Retpoŝtaj mesaĝoj per MAP Poŝtelefona mesaĝado per retpoŝto fariĝis grava apliko de Bluetooth-teknologio en la aŭto. Bludento kovris ĉi tiun uzkazon per la disvolviĝo de Message Access Profile (MAPO, [1]). Tamen MAP permesas al la aŭta ilaro esti poŝta kliento de la poŝtelefono. Ĝi ne provizas kapablojn por sendi / ricevi retpoŝtojn flanke de MAP-kliento.
   * Speciala uzokazo: Administrado de Personaj Informoj La Bluetooth SIG nuntempe disvolvas profesiulonfile ebligante aliron al la kalendaraj datumoj per la poŝtelefono. Ĉar kalendaraj enskriboj kutime liveriĝas per retoj IP, perdo de la IP-rilato ankaŭ influus ĉi tiun uzokazon. Tial poŝtelefono funkcianta en SAP devas povi sendi kaj ricevi tiajn kalendarajn enskribojn
2. SMS
   Poŝtelefona mesaĝado per SMS estas ankoraŭ grava merkato. Sekve, SMS-mesaĝoj devas esti eblaj ankaŭ por poŝtelefono funkciigita per SAP.
3. Voĉo nur
   La SAP-avantaĝofile devenas de la jaro 2000, kaj tial temas pri voĉvoko. Smartphones, kun ilia bezono de konstanta interreta konekto, ne estis konsidero. Tamen uzi SAP nur por voĉa telefonio estas ankoraŭ valida uzokazo. La nurvoĉa uzkazo estas kovrita de la ekzistanta specifo kaj ne bezonas iujn ajn ŝanĝojn.

3. Solvoj

3.1 SUPERVIEW

La sekvaj sekcioj priskribas la solvojn, kiujn oni povas apliki por trakti la aferojn, kiel priskribite en sekcio 2:

1. Interreta atingo:
   Poŝtelefono aŭ alia poŝtelefono aganta kiel SAP-servilo devas esti ebligitaj por aliri al la interreto.
2. SMS-Transigo:
   Poŝtelefono aŭ alia poŝtelefono aganta kiel SAP-servilo devas esti ebligitaj por sendi kaj ricevi SMS-mesaĝojn.
3. Voĉo Nur:
   SAP estas uzata nur por voĉa telefonio.

Kiel ĝenerala limo, la solvoj priskribitaj en la sekvaj sekcioj estu kiel eble plej travideblaj por la uzanto; la uzanto ne devas zorgi ĉu SAP aŭ HFP funkcias.
Aldone, la SAP-servila aparato restos la centra unuo por la komunikado; ekz. la historioj pri eniraj kaj eksiĝintaj komunikaj transakcioj, kiel senditaj aŭ ricevitaj mesaĝoj, devas ankoraŭ esti haveblaj sur la SAP-servilo.
La traktado de MMS en SAP-operacio ne estas eksplicite priskribita de ĉi tiu blanka libro. Tamen, ĉar MMS postulas kaj ricevadon de SMS kaj IP-konekton al la MMS-servilo, la problemo estas implicite kovrita de la uzkazoj SMS-Transdono kaj Interreta Aliro.

3.2 INTERRETA ALIRO

3.2.1 ĜENERALA KAZO DE INTERreta ALIRO

Celo:
Donu aliron al la fora IP-reto por la SAP-servila aparato dum SAP estas aktiva Priskribo:
La SAP-servila aparato (ekz. Poŝtelefono aŭ dolortelefono) disponigis aliron al siaj SIM-datumoj por la SAP-klienta aparato (ekz. Aŭta kitaro aŭ tablojda komputilo) kaj la SAP-kliento uzis ĉi tiujn datumojn por la aŭtentokontrolo kontraŭ la poŝtelefona reto. Sekve, la SAP-servilo havas neniun aliron al la poŝtelefona reto, dum la SAP-kliento uzas sian propran retaliran aparaton (NAD) por komuniki kun la poŝtelefona reto.
Por provizi interretan aliron por la SAP-servilo, la SAP-klienta aparato devas funkcii kiel retalira punkto por la SAP-servilo. Por tio, IP-ligo inter la SAP-servilo kaj SAP-klientaj aparatoj devas esti establita.
La solvo priskribita ĉi tie uzas la protokolon Bluetooth BNEP por la IP-ligo inter la du SAP-aparatoj kaj la PAN-profesiulofile provizi la retaliran punkton. Notu, ke aliaj solvoj eble eblas, ekz. IP-konekto per WiFi.
Por la ĉi tie difinita solvo, la jenaj antaŭkondiĉoj devas esti plenumitaj:

• La du aparatoj havas SAP-ligon establitan.
• La SAP-servila aparato devas subteni la rolon PANU (PAN-Uzanto) de la PAN-profesiulofile [3].
• La SAP-klienta aparato devas subteni rolon NAP (Network Access Point) de la PAN-profesiulofile.

Figuro 1 montras la konektan aranĝon por ebligi al la SAP-servilo aliri la eksteran IP-reton:

Bildo 1: Sekvenco de la konekto-aranĝo PAN / BNEP

1. Se la SAP-konekto estas establita inter la du aparatoj kaj aplikaĵo sur la SAP-servila aparato postulas IP-konekton al la fora reto, la SAP-servila aparato (PANU-rolo) starigas PAN / BNEP-konekton al la SAP-kliento (PAN-NAP rolo). Tipe, ĉi tiu PAN-liga starigo ne postulos uzanton.
2. La agordo de konekto BNEP devas inkluzivi la transdonon de datumoj pri alirpunkta nomo (APN) aŭ elekton de antaŭdifinitaj APN-oj sur la SAP-klienta aparato kiel difinita en [4].
3. Post la sukcesa starigo de la konekto PAN / BNEP, IP datagvirŝafoj povas esti aŭtomate transdonitaj inter la SAP-servila aparato kaj la fora reto, kie la SAP-klienta aparato funkcias kiel enkursigilo al la fora IP-reto.
4. Pluraj PAN / BNEP-ligoj povas esti establitaj kiel priskribite supre, ekz. Por trakti plurajn alirpunktojn en la infrastrukturo de la poŝtelefona reto.

La sekvaj sekcioj priskribas la uzadon de la ĝenerala mekanismo supre por iuj specifaj aplikoj.

3.2.2 SPECIALA KAZO DE UZO: Retpoŝta ALIRO PER MAPO

Celo:
Ebligu SAP-servilan aparaton sendi kaj ricevi retpoŝtojn dum SAP estas aktiva.
Priskribo:
Unu specifa aplikaĵo por la interreta alira mekanismo priskribita supre estas la transdono de retpoŝtoj per la mesaĝo Access Profile [1].

Por MAP-sesio kun SAP-operacio la jenaj antaŭkondiĉoj devas esti plenumitaj:

• La ĝeneralaj postuloj por interreta aliro kiel priskribitaj en sekcio 3.2.
• La SAP-servila aparato funkcias kiel MAP-Servila Ekipaĵo (MSE) kaj la SAP-kliento funkcias kiel MAP-Klienta Ekipaĵo (MCE).
• Kaj la MSE kaj la MCE subtenas la MAP-funkciojn 'Mesaĝo-Foliumado', 'Mesaĝo-Alŝuto', 'Mesaĝa Sciigo' kaj 'Sciiga Registrado'

Figuro 2 priskribas la sekvencojn kaj la uzadon de la MAP-funkcioj por retpoŝta ricevo:

Figuro 2: Sinsekvo de retpoŝta ricevo en MAP kun SAP-operacio

1. La aparatoj MAP MSE kaj MCE establis ligon 'Message Access Service' kaj 'Message Notification Service' ligon.
2. La SAP-servila aparato (kiel PANU) establis PAN / BNEP-ligon al la SAP-klienta aparato (kiel PAN-NAP).
3. La MSE prenas la retpoŝton uzante la PAN / BNEP-konekton de la reto per NAD de la MCE.
4. La MSE sendas sciigon 'NewMessage' al la MCE signalante, ke nova mesaĝo ricevis.
5. La MCE povas retrovi la mesaĝon per peto 'GetMessage'.

Vidu ankaŭ [1] por priskriboj de la MAPaj funkcioj 'SendEvent' kaj 'GetMessage'.

Figuro 3 priskribas la sekvencojn kaj la uzadon de la MAP-funkcioj por sendi retpoŝton:

Bildo 3: Sekvenco por sendi retpoŝton en MAP kun SAP-operacio

1. La aparatoj MAP MSE kaj MCE establis ligon 'Message Access Service' kaj 'Message Notification Service' ligon.
2. La SAP-servila aparato (kiel PANU) establis PAN / BNEP-ligon al la SAP-klienta aparato (kiel PAN-NAP).
3. Se la mesaĝo estas kreita sur la MCE-aparato, la MAS-Kliento de la MCE puŝas la mesaĝon al la dosierujo 'Elirkesto' de la MSE. Se la mesaĝo estas kreita sur la MSE-aparato kaj preta por esti sendita, la mesaĝo estas agordita en la elirkesta dosierujo aŭ ŝanĝita de la projekta dosierujo.
4. Se la mesaĝo estas puŝita al la dosierujo 'Elirkesto', la MSE sendas sciigon 'NovaMesaĝo' al la MCE signalante, ke la mesaĝo estis akceptita. Se mesaĝo kreiĝis aŭ translokiĝis al la dosierujo 'elirkesto' en la MSE, la MSE sendas eventon 'MessageShift'.
5. La MSE sendas la mesaĝon al la reto per sia konekto PAN / BNEP.
6. Se la mesaĝo estis sukcese sendita al la reto, la MSE ŝanĝas la mesaĝon de la "Elirkesto" al la dosierujo "Sendita" kaj sekve informas la MCE.

Vidu ankaŭ [1] por priskribo de la MAPaj funkcioj 'SendEvent' kaj 'PushMessage'.

3.2.3 SPECIALA KAZO: KALENDARO DE DATENOJ

Celo:
Ebligu SAP-servilan aparaton sendi kaj ricevi kalendarajn datumojn dum SAP estas aktiva.
Priskribo:
Alia specifa aplikaĵo por la interreta alira mekanismo (3.2.1) priskribita estas la transdono de kalendaraj datumaj enskriboj per IP-reto. La disvolviĝo de kalendara profesiulofile progresas ekde la verkado de ĉi tiu blanka libro, do ankoraŭ ne estas detalaj funkcioj difinitaj.
Tiel, nur skiza sinsekvo de la bezonataj agoj estas donita ĉi-sube. Ĝenerale la postuloj por ĉi tiu uzokazo estos similaj al la postuloj por retpoŝta aliro (vidu 3.2.2).

Bildo 4: Skema sinsekvo por ricevo de kalendaraj datumoj en SAP-operacio

Bildo 5: Skema sinsekvo por sendi kalendarajn datumojn en SAP-operacio

3.3 UZU KAZAN SMS-ALIRON

3.3.1 SUPERVIEW

Celo:
Priskribu la mekanismojn por SAP-servila aparato sendi kaj ricevi SMS dum SAP estas aktiva.
Priskribo:
La SAP-servila aparato (ekz. Poŝtelefono aŭ dolortelefono) disponigis aliron al siaj SIM-datumoj por la SAP-klienta aparato (ekz. Aŭtomobila ilo aŭ tablojda komputilo) kaj la SAP-kliento uzis ĉi tiujn datumojn por la aŭtentokontrolo kontraŭ la poŝtelefona reto. Tiel, la SAP-servilo ne plu povas sendi aŭ ricevi SMS-mesaĝojn rekte.
Por ebligi al uzanto sendi aŭ ricevi SMS-mesaĝojn, du aliroj estas priskribitaj ĉi-sube:

• Simpla solvo bazita nur sur SAP
• Pli kompleksa sed ĝisfunda aliro bazita sur MAP

3.3.2 SMS-ALIRO NUR PER SAP

Ricevi SMS:
Funkciante en SAP-reĝimo, la NAD de la SAP-kliento ricevas SMS_DELIVER PDU aŭ SMS_STATUSREPORT PDU kiel difinite en 3GPP 23.040 per la poŝtelefona protokola stako de la NAD. Depende de la reguloj difinitaj en 3GPP 23.040 kaj 3GPP 23.038 por la SMS-PDU ricevita de la NAD, la SAP-klienta aparato tiam povas stoki la SMS ĉe la (U) SIM de la SAP-servila aparato. Por tio, ĝi uzas la SAP-APDU-formaton por peti la stokadon de la PDU per la SAP-konekto sur la (U) SIM en la elementa kampo EF [SMS] de la (U) SIM (vidu 3GPP 51.011 v4 ĉapitro 10.5.3 por la difino de la kampo). Per ĉi tio, la ĝisdatiga procedo laŭ 3GPP 51.011 ĉapitro 11.5.2 kaj 3GPP 31.101 plenumiĝas.
Sendu SMS:
La SMS_SUBMIT PDU (vidu 3GPP 23.040) estas sendita per la protokola stako de la NAD-poŝtelefono. Post sendado, depende de la reguloj difinitaj en 3GPP 23.040 kaj 3GPP 23.038 por la SMS PDU, la NAD tiam povas stoki la SMS ĉe la (U) SIM. Denove ĝi uzas la formaton SAP APDU por peti konservi la PDU kaj uzas la ĝisdatigan proceduron laŭ 3GPP 51.011 ĉapitro 11.5.2 kaj 3GPP 31.101.

Avancotages

• Plena plenumo de postuloj pri poŝtelefona reto 3GPP plenumiĝas.
• SMS estas konservitaj ne-volatilaj sur (U) SIM-loko ene de la poŝtelefono.
• Malpli da komplekseco kompare kun solvo "Plena SMS-Aliro" priskribita en sekcio 3.3.3 kiel neniu aldona profesiulofile necesas. Tiel, ĉi tiu solvo taŭgas ankaŭ por simplaj aparatoj.

Malavantaĝotages

• Efektivigoj de poŝtelefonoj povus ignori la (U) SIM EF [SMS] tiel ke la kliento eble ne povos aliri la senditajn aŭ ricevitajn SMS per la uzantinterfaco de la poŝtelefono post kiam la SAP-konekto finiĝis.
• Ĉar la telefono ne havas aliron al la SIM-karto dum SAP-operacio, la mesaĝoj ne estos montrataj sur la telefono dum SAP-operacio.
• Neniu komenco de SMS-sendado per la poŝtelefono eblas.

3.3.3 PLENA SMS-ALIRO PER MAPO

La ĉefa celo de la alproksimiĝo ĉi tie priskribita estas, ke la SAP-servila aparato estu ĉiam enmetita en la SMS-komunikadon. Ĉi tio certigas, ke la SMS-aliro estas tute travidebla por la uzanto, ĉar ĉiuj historioj pri senditaj kaj ricevitaj SMS-mesaĝoj estas en la mesaĝdeponejo de la SAP-servila aparato.
Por tio, la SMS-PDU-oj ricevitaj de la fora reto estas aŭtomate transdonitaj de la NAD de la SAPclient al la SAP-kliento, kaj inverse, por sendado per la funkcioj OBEX de la Message Access Profile. Por ĉi tiu solvo, la jenaj antaŭkondiĉoj devas esti plenumitaj:

• La du aparatoj havas SAP-ligon establitan.
• La SAP-servila aparato funkcias kiel MAP-Servila Ekipaĵo (MSE) kaj la SAP-klienta aparato funkcias kiel MAP-Klienta Ekipaĵo (MCE).
• Kaj la MSE kaj la MCE subtenas la MAP-funkciojn 'Mesaĝo-Foliumado', 'Mesaĝo-Alŝuto', 'Mesaĝa Sciigo' kaj 'Sciiga Registrado'
• La du aparatoj establis konekton 'MAS (Message Access Service Service) (MAS) kaj ligon' MNS (Message Notification Service) (MNS).

Figuro 6 priskribas la sekvencojn kaj la uzadon de la MAP-funkcioj por SMS-ricevo:

Bildo 6: Sekvenco de SMS-ricevo per MAP en operacio SAP

1. La SAP-Kliento / MCE ricevas la SMS per sia NAD de la reto.
2. La MAS-Kliento de la MCE puŝas la SMS-PDU aŭ - en kazo de kunligita SMS - la SMS-PDU al la dosierujo 'Enirkesto' de la MSE en denaska SMS PDU-formato.
3. Se la SMS estas por la uzanto (t.e. neniu SMS de klaso 2), la MSE sendas sciigon 'NovaMesaĝo' al la MCE signalante, ke nova SMS ricevis.

Figuro 7 priskribas la sinsekvon kaj la uzadon de la MAP-funkcioj por sendi SMS:

1. Se la SMS estas kreita sur la SAP-kliento / MCE-aparato, la MAS-Kliento de la MCE puŝas la SMS al la dosierujo 'Elirkesto' de la MSE. La SMS estas transkodita al SMS-sendota-PDU-formato fare de MSE, se ĝi estis puŝita laŭ teksta formato. Se la SMS estas kreita sur la MSE-aparato kaj estas sendota, la mesaĝo estas agordita en la dosierujo 'Elirkesto' aŭ ŝanĝita de la projekta dosierujo.
2. La MCE prenas la SMS-submit-PDU de la dosierujo 'Elirkesto' de MSE per peto 'GetMessage' kaj sendas ĝin al la reto.
3. Kiam sukcese sendita al la reto, la MCE fiksas la staton de la mesaĝo al "sendita".
4. La MSE ŝanĝas la mesaĝon de la "Elirkesto" al la dosierujo "Sendita" kaj informas la MC pri tio.

Avancotages:

• Kvalifikinda solvo.
• SMS estas dividitaj reen al la telefono dum SAP-operacio.

Malavantaĝotages:

• Kompleksa efektivigo postulas havi MAP kaj SAP efektivigitajn sur ambaŭ aparatoj.
• Postulas ke ambaŭ MAP kaj SAP estu konektitaj kaj funkciantaj samtempe por ke neniuj SMS estu perditaj.
• Ĉar la telefono eble ne havas aliron al la SIM-karto dum SAP-operacio, la mesaĝoj eble ne aperas sur la telefono dum SAP-operacio.

3.4 UZU KAJ SAP TELEFONIO NUR

SAP-servilo kaj SAP-kliento eble havas SAP-ligon establitan kun la sola celo provizi voĉan telefonion en plej bona kvalito. Ĉi-kaze neniuj pliaj postuloj difinitaj por SAP devas esti konsiderataj.

4. Mallongigoj

Mallongigo aŭ Akronimo:  Signifo

3GPP:  3-a Generacia Partnereco-Projekto
BNEP:  Bluetooth Network Encapsulation Protocol
GSM:  Tutmonda Sistemo por Poŝtelefona Komunikado
HFP:  Senmane-Porfile
IP:  Interreta Protokolo
MAS:  Servo pri Alira Mesaĝo
MAPAO:  Message Access Profile
MCE:  Mesaĝa Klienta Ekipaĵo
MMS:  Plurmedia Mesaĝa Servo
MNS:  Servo pri Mesaĝa Sciigo
MSE:  Mesaĝa Servila Ekipaĵo
MWS:  Movebla Sendrata Kunekzistado
NAD:  Reta Alira Aparato
PATRONO:  Persona Area Reta Profesiulofile
PDU:  Protokolo-Datunuo
SUKO:  SIM Access Profile
SIM:  Modulo de Identeco de Abonanto
SMS:  Mallonga Mesaĝa Servo

5. Referencoj

1. Message Access Profile 1.0
2. SIM Access Profile 1.0
3. Persona Area Reta Profesiulofile (PAN) 1.0
4. Protokolo Bluetooth Encapsulation Network (BNEP), Versio 1.2 aŭ posta
5. Logika Interfaco MWS-Kunekzistado, Aldona Specifo Bluetooth-Kerna 3 rev. 2

 

Instrukcia Manlibro pri SAP kaj Fora Aliro - Optimigita PDF
Instrukcia Manlibro pri SAP kaj Fora Aliro - Originala PDF

Referencoj

• Uzanto Manlibro