Open Mobile Alliance (OMA)(Nokia, Motorola, Ericsson, Unwired Planet) ... 5 n 5. Wiedervorlage...

Open Mobile Alliance (OMA)

Standardisierung mobiler Anwendungen

Firmenvortragadare GmbH

www.adare.deUwe Stahl

Tel.: +49 7152 907133Email: [email protected]

Oktober 2005

Agenda

Was ist OMA?Wie arbeitet ein Standardisierungsgremium?Der Entwicklungsprozess für die Spezifikation (mobiler) AnwendungenBeispiel für mobile Anwendung: PoCNoch mehr Spezifikationen: Tests zur Sicherstellung der InteroperabilitätProduktbeispiel Conformance-Testeradare GmbH – Protokollimplementierung & Testautomatisierung im Mobilfunk

OMA Open Mobile AllianceARPU Average Revenue Per User

Was ist OMA? (1)

Globale Organisation der Mobilfunkindustrie seit 2002Mission: Durch mobile (Daten-) Anwendungen eine weitere Wachstumswelle des Mobilfunks zu initiieren (Increase ARPU, ...)Mehr als 350 Mitgliedsfirmen*):(Integration mehrererVorgängerforen) - Hersteller

(Geräte, HW-, SW-Komponenten) - Netzbetreiber- Dienst-/Content-Anbieter- Medienindustrie

Formal: Gesellschaft englischen Rechts (Nokia, Motorola, Ericsson, Unwired Planet)

* Vergleich ETSI > 600 Mitglieder

Was ist OMA? (2)

Mitgliedskategorien (und Gebühren p.a.)- Sponsor 130.000 $

- Full Member 32.500 $

- Associate Member 7.500 $

Ergebnisse- Spezifikationen/Standards für mobile Anwendungen

- Gemeinsam erarbeiten

- Basis für Produktimplementierungen

OMA Prinzipien (1)

Offene, globale Standards(minimale Marktfragmentierung)

Netz-unabhängige Anwendungen(GSM, GPRS, EDGE, CDMA, UMTS) Unabhängigkeit von BetriebssystemenInteroperabilität- Zwischen Geräten

- Über Netze hinweg (Roaming)

- Zwischen Infrastruktur und Dienstanbietern

IPR Intellectual Property Right

OMA Prinzipien (2)

Festgefügte Regeln für die Zusammenarbeit(wie alle normativen Gremien)- Prozesse- Ämterbesetzung und Verantwortlichkeiten- Klassifizierung und Kennzeichnung von Dokumenten - Entscheidungsprozesse/Abstimmungen- IPR policy = Vereinbarung zu Patenten:

AnzeigepflichtGewähr von Lizenzen zu fairen Konditionenfür alle Patentrechte betreffend OMA Spezifikationen

- ... - Verfahren bei Interoperabilitätstest und Umgang mit

Ergebnissen

OMA Begriffe

Terminologie- Mobile Application

- (Data)-Service

- OMA: Service Enabler

Enabler Release - Satz zusammengehöriger Spezifikationsdokumente für eine

Anwendung

- Unterscheidung 2 Arten von ReleasesPhase 1 = Candidate Enabler

Phase 2 = Approved Enabler Release(Implementierungen haben Interoperabilitätstests bestanden)

Beispiele mobiler Anwendungen von OMA

WAP - Wireless Application Protocol (Integration des WAP Forums) IMPS - Instant Messaging & Presence Service(aus Wireless Village)MMS - Multimedia Messaging ServiceDRM - Digital Rights ManagementPoC - Push to talk over Cellular...Client Provisioning...In Summe 25 Enabler- 28 Candidate- 11 Approved

OMA –eine re

cht agile

Großmutter!

OMA und andere Standardisierungsgremien

Internet Domain Mobile Domain

OMA Open Mobile Alliance3GPP 3rd Generation Partnership ProjectIETF Internet Engineering Task ForceW3C WWW Consortium

W3CW3C

IETF

Abstützen auftechnische Basis

OMAApplicationLevel Ziel: Anwendungen für

Infrastruktur / technischjedoch unabhängigInfrastructure

Level

3GPP

Agenda


OMA Organisation (1)

TP Technical PlenaryWG Working GroupSWG Sub Working Group

OMA Organisation (2)

Board of Directors = Offizielle Vertretung, Ressourcenplanung Technical Plenary = Steering Board / Lenkungsausschuss Comittees = Unterstützung bei Planung & Verfahren Technische WGs- Enabler-bezogene für technische Hauptarbeit

Browser & Content...

- Spezialisierte WGs = Querschnittsfunktionen für alle Enablers

Requirements ArchitectureIOP Interoperatibility (z.T. Security)

OMA Arbeitsweise (1)

Treffen, typisch 6 x pro Jahr- 3x mit TP, WGs, Committees, Bord

- 3x nur WGs

Telefonkonferenzen von WG bzw. SWG typischerweise im WochenrhythmusElektronische Kommunikation- List-Server für E-Mail-Gruppen

- Informationen, Dokumente auf OMA Webside (für Mitglieder)

TestFests abhängig von Nachfrage; ca. 3 pro Jahr(Testen der Interoperabilität unterschiedlicher Implementierungen)

OMA Arbeitsweise (2) (vereinfachte Darstellung)

z.B. Klärung – Konsens

TP

Bestehendeoder neue WG

Ad-hocGruppe

1

1

2

3

45

n5

Wiedervorlage

Übergabe Work Item

n+2 PublicReview

> 30 Tage

n+1z.B.

Vorschlagfür neuen

Enabler

Zustimmung

Ergebnissezur Verabschiedung

Berichte, ...

InformelleSWG technische Arbeit 3-Stage-Method

Zeit

Agenda


3-stufige Entwicklungsmethode (1)

Gesamter OMA Prozess kennt eigentlich mehr Stages- Work Item Erstellung

- ... technische Entwicklungsarbeit

- Post Technical Plenary Approval Prozess nach Phase 2

Im Folgenden - Beschränkung auf technischen Entwicklungsprozess

- 3-Stage-Method, wie sie auch von anderen Standardisierungsgremien*) angewendet wird

- 3-Stage-Method in OMA Prozess eingebettet

1

2020

* z.B. ITU-T, ETSI, 3GPP, ...


Stage 1: Spezifikation der Anwendung- Funktionale Beschreibung aus Nutzer-Sicht

- Hilfsmittel: Use Cases (informativ)

- Requirements (normativ), mit Unterscheidung

- Mandatory

- Optional

- Durchführung bei OMA (auch anderen Gremien) durch spezialisierte Gruppe

- Ergebnis: Requirement Document (Typ RD)


Stage 2: Spezifikation der Architektur - Aufteilung der Funktionalitäten auf Einheiten in Endgeräten

und Netzknoten(unter Zugrundelegung einer Basisarchitektur)

- Festlegung von Referenzpunkten/Schnittstellen zwischen den funktionalen Einheiten

- Spezifikation von Steuer- u. Nutzdaten-Flows zwischen den funktionalen Einheiten

- Auswahl von Basisprotokollen für die Realisierung von Steuersignalen und Nutzdatenübertragung

- In OMA Enabler WG/SWG zusammen mit Architektur-WG

- Ergebnis: Architecture Document (Typ AD)

RD Requirement DocumentAD Architecture DocumentTS Technical Specification


Stage 3: Protokollspezifikationen- Stage 1 Dokument: Feinspezifikationen

- Detaillierte Prozeduren in den funktionalen Einheiten

- ProtokolleNeue Protokollnachrichten

Anwendung von bestehenden Protokollen- Nachrichten

- Informationselemente

- In OMA Enabler WG/SWG

- Ergebnis: Satz von Technical Specifications (Typ TS)(Referenzen auf Basisprotokollspezifikationen)


Welche Dokumente wofür?

Stage 1 Kurzer Überblick – Was aus Nutzersicht

Stage 2 Überblick / Einarbeitung – Wie realisiert

Stage 3 Verbindlich - Wie zu implementieren !

Agenda


PoC Push to talk over Cellular

PoC – Sprachdienst ähnlich Instant Messaging

Push to talk, d.h. auf Knopfdruck Halb-Duplex SprachkommunikationPoC Kommunikationsszenarios- 1-to-1 - Ad-hoc Gruppe (z.B. Mitglieder eines Fahrradausflugs)- Pre-arranged Gruppe (z.B. Service-Team einer Firma)- Chat Gruppe (z.B. Gruppe für Skigebiet)

Features- Session Arten

Pre-established Session (Medienfestlegung bei Netzregistrierung) Ad-hoc Session (Medienfestlegung je bei Session-Beginn)

- PoC Alert- PoC Barring- Manual Answer & Automatic Answer- Manual Answer Overwrite, ... Aus Stage 1 Dokument

PoC – Mobilfunknetzarchitektur UMTS

GPRSSGSN GGSN

IU-CS

RNC

MSCMSC

IU-PS

andereSprachnetze

CS Domainprimär für Sprachdienste

IP-Netz,Internet

UE

NodeBCS Circuit SwitchedPS Packet SwitchedRNC Radio Network ControllerMSC Mobile Switching CenterGPRS General Packet Radio ServiceGGSN Gateway GPRS Support NodeSGSN Serving GPRS Support NodeUE User Equipment=mobile station

PS Domainfür Datendienste

PoC Prinzip: VoIP Client Server Realisierung

PoC - VoIP

...

...

AMR Adaptive Multi RateAudio Codec

Beispiel AMR Mode 5,15 kbit/s- Audio Samples 103 bit / 20 ms- 8 Samples in ein RTP Paket / 160 ms

(d.h. 5,6 kbit/s auf RTP-Layer)- Je RTP Paket 112 byte gemäß RFC 3267- Qualität „etwas blechern“ aber gut verständlich

XDM XML Document ManagementXDMC XDM ClientXDMS XDM ServerDM Device Management

PoC – Stage 2: ArchitekturQuelle: OMA



PoCKern



Group ListManagement

PoCKern




Inter-workingmit Presence

PoCKern




Inter-workingmit Presence

Setzen vonParametern durch Netz

PoCKern

PoC – Flows: SIP Registrierung

REGISTER

SUBSCRIBE (Event: reg)

200 OK

NOTIFY (XML)

200 OK

PoC Clientaktivieren

PoC ServerPoC

Client

SIP Session Initiation Protocol

401 Unauthorized (Authorization Key)

REGISTER (Authorization Response)

200 OK

Sync.Service

SettingsSIP/IP Corebzw. IMS



IP Multimedia System

PoC – IP Multimedia System AS AS AS

P-CSCF I-CSCF S-CSCF

VisitedNetwork

HomeNetwork

S-CSCF

HSS

Funkzugang,GPRS

AirInterface

CSCF Call State Control FunctionP-CSCF Proxy-CSCFI-CSCF Interrogating-CSCFS-CSCF Serving-CSCF AS Application ServerHSS Home Subscriber Server

IP Mutimedia Subsystem (IMS) ist eine Netzplattform für SIP-basierte Dienste

IMS unterstützt Roaming, Lastverteilung im Netz und die Anschaltung netz-externer Application Server

SIP-Routing über Proxies P-CSCF- I-CSCF – S-CSCF –> AS

Autorisierung (Nutzungsberechtigung für IMS und Applikationen)über zentralisierte Teilnehmerdatenbank HSSNetz-interne Funktionen für Entgelterfassung, Abhören, …

PoC – Flows: Beispiel für Session Aufbau

SIP INVITE

SIP 100 Trying

PoC Client A PoC Server

PoC Client B, ...

SIP INVITE

Gruppeaktivieren

TBCP Talk Burst Control Protocol

TBCP

SIP 180 RingingSIP 180 Ringing

Rufsignal

SIP 200 OKSIP 200 OK

Talk Burst TakenSIP ACK

SIP ACKTBCP Talk Burst Grant

Rufannahme

Sprechsignal(Piepton)

Sprechtaste drücken

SIP INVITE = implizites TBCP Talk Burst Request

PoC – Flows: Steuerung des Senderechts

RTP(AMR)

PoC Client A PoC Server

PoC Client B, ...

RTP(AMR)

RTP(AMR)

RTP(AMR)

RTP(AMR)

RTP(AMR)

RTP Real Time ProtocolAMR Adaptive Multi Rate (Codec)

TBCP Talk Burst Idle

Sprechen Empfang

Sprechtasteloslassen

TBCP Talk Burst End

TBCP Talk Burst Idle

SprechtastedrückenTBCP Talk Burst Request

TBCP Talk Burst Taken TBCP Talk Burst Grant Sprechsignal(Piepton)

RTP (AMR)RTP (AMR) Sprechen

PoC – Flows: Group List Management

HTTP PUT(buddy list)

HTTP DELETE (buddy list)

HTTP 200 OK

PoC XDMServer

PoC XDM

Client

HTTP 201 CREATED

HTTP PUT(buddy)

HTTP 200 OK

HTTP GET(buddy list)

HTTP 200 OKAggregationProxy -Ähnlich IMS

SDP Session Description ProtocolRTCP Real Time Control Protocol SR, RR Sender Report, Receiver ReportXCAP XML Configuration Access Protocol

PoC – Stage 3: Stackdarstellung Protokolle

von OMA spezifiziert

*Ausgabeständez.T. veraltetPoC – Spezifikationen*)

OMA Spezifikationen (PoC Applikation)(abbr.) Title Content Document IDRequirements Service description/use cases (stage1) OMA-RD_PoC-V1_0-20040628Architecture Entities/ functions/ flows (stage 2) OMA-AD_PoC-V1_0-20040824Control plane SIP signalling flows (stage 3) OMA-CP_PoC-V1_0-20040827User plane RTP, RTCP, TBCP protocols (stage 3) OMA-UP_PoC-V1_0-20040830... ... ...

(abbr.) Title Content Document IDSIP Session Initiation Protocol RFC 3261SDP Multimedia session description RFC 2327SIP-specific event notification Generic notification mechanism RFC 3265Event package for registrations Specific notification for registrations RFC 3680RTP for AMR (& AMR-WB) Specific payload and file storage format RFC 3267RTP Generic RTP & RTCP (including APP) RFC 3550... ... ...

3GPP Spezifikationen (IMS Core)(abbr.) Title Content Document IDService requirements for IMS Stage 1 description TS 22.228 V5.6.0 (2002-06)IMS stage 2 Stage 2 description TS 23.228 V6.7.0 (2004-09)IMS Call Control for SIP/SDP SIP & SDP application/RFC profiles (stage 3) TS 24.229 V5.10.0 (2004-09)IMS Signalling based on SIP/SDP SIP & SDP signalling flows (stage 3) TS 24.228 V5.11.0 (2005-01)... ... ...

IETF Spezificationen (Internet Technologie)

Agenda

Was ist OMA?Wie arbeitet ein Standardisierungsgremium?Der Entwicklungsprozess für die Spezifikation (mobiler) AnwendungenBeispiel für mobile Anwendung: PoCNoch mehr Spezifikationen: Tests zur Sicherstellung der InteroperabilitätProduktbeispiel Conformance-Tester

ETR Enabler Test RequirementsETP Enabler Test PlanETS Enabler Test Specification

Noch mehr Spezifikationen

Spezialisierte WG IOP(InterOPperability)

Erstellt Test-Requirements (ETR) und Test Plan (ETP) in Spezifikationsendphase

Started Erstellung einer Testspezifikation (ETS)wenn der Enabler Candidate (Phase 1) vorliegt

Testspezifikation umfasstInteroperabilitäts-Tests

Conformance Tests für

Client

Server

Interoperabilität & Conformance TestZiel: Verträglichkeit Herstellerprodukte Ziel: Einhaltung Spezifikation

Hersteller 1 2 ... N

Mobile Conformance Tester

Server Conformance Tester

Anzahl Tests = N+M

Hersteller 1 2 ... M

Anzahl Tests = N*M

Methodik*) - SCR *OMA in Anlehnung an ISO 9646

SCR Static Conformance RequirementsHerunterbrechen der Spezifikationen ineinzelne Features und deren Kennzeichnung Klassifizierung von diesen in

Mandatory (MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT)

Optional (SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL)

Maschinenverarbeitbare SCR-NotationSCR Tabellen erfassen alle Client/Server Features

Methodik*) - SCR *OMA in Anlehnung an ISO 9646

SCR Static Conformance RequirementsHerunterbrechen der Spezifikationen ineinzelne Features und deren Kennzeichnung Klassifizierung von diesen in

Mandatory (MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT)

Optional (SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL)

Maschinenverarbeitbare SCR-NotationSCR Tabellen erfassen alle Client/Server Features

Beispiel: Auszug aus PoC Client SCRs

Methodik – Test CasesTest Spezifikation = Test Case Sammlung für alle SCRs


Beispiel Test Case für PoC Client


Beispiel Test Case für PoC Client

Testimplementierung

Methodik - EICSEICS Enabler Implementation Conformance Statements

Liste SCR-Items einer Herstellerimplementierung

Machinenlesbare Notation

ZweckÜberprüfung, ob Mindestfunktionalität bzw.konsistentes Set an Funktionalität gewährleistet

Auswahl der anwendbaren Test Cases

... Filtern...

Produkt-EICS

TestSpezifikation

(ETS)

AnwendbareTest Cases(Conformance &Interoperabilität)

Agenda


Conformance Tester Implementierung

DUT*) = PoC Client in Mobilfunktelefon Anwendbare Test Casesmit machinenlesbaren

Testschritten & Pass Criteria

...

*DUT = Device under Test




Test Steuerung

GUI - Konfiguration- Testlaufkontrolle- Anweisungen an Testerbzgl. BedienungMobilfunktelefon

...

Befehle Resultate

PoC Server

Interpreter

*DUT = Device under TestIP




Test Steuerung

GUI - Konfiguration- Testlaufkontrolle- Anweisungen an Testerbzgl. BedienungMobilfunktelefon

...

Befehle Resultate

PoC Server

InterpreterTestgerät für Funkschnittstelle

inkl.GPRS Simulation

*DUT = Device under TestFunkschnittstelle IP

Conformance Tester AnforderungenTests müssen gegen geschlossenes Produkt laufen- Vorgabe Global Certification Forum (GFC)

(Gültigkeit durch Selbstverpflichtung der Hersteller) - Keine Testanordnung für DUT (z.B. Soft-Client) möglich - Test erfordert Funkschnittstelle

Conformance Test Implementierungen müssen durch Testinstitute überprüft und selbst zertifiziert werden- Ähnlich Eichverfahren- Gilt nach jeglicher Änderung!

Conformance Test Produkte werden von Testgerätehersteller implementiert und angeboten- Beispiel Protokolltester CRTU-W

von Rohde & Schwarz

TTCN Tree & Tabular Combined NotationSDL Specification & Description LanguageMSC Message Sequence Charts

Herausforderungen für den IngenieurEinarbeitung in die Anwendung & deren technische Realisierung, insbesondere die Protokolle (Stage 3)

Wissen über Protokollmechanismen, Kenntnisse von Protokollen, Kodierungsarten, ...

Entwicklung von Teilen der Anwendung zur SimulationSW-Entwicklungsarbeit mit gängigen Programmiersprachen und WerkzeugenHohe Anforderungen an die Übereinstimmung der Implementierung mit den Spezifikationen/ProtokollenGeringe Anforderungen an die Leistungsfähigkeit und Kapazität der Implementierung

Kenntnis von Testmethoden, -Sprachen und WerkzeugenIm Beispiel wurde das Werkzeug neu entwickeltStandard-basierende Tools (TTCN, SDL, MSC) Produktspezifische Scriptsprachen von ProtokolltesternAnalytische Fähigkeiten bei der Fehlerdiagnose

Agenda

Was ist OMA?Wie arbeitet ein Standardisierungsgremium?Der Entwicklungsprozess für die Spezifikation (mobiler) AnwendungenBeispiele für mobile AnwendungenNoch mehr Spezifikationen: Tests zur Sicherstellung der InteroperabilitätProduktbeispiel Conformance-Testeradare GmbH – Protokollimplementierung & Testautomatisierung im Mobilfunk

adare – bitte nicht verwechseln mit …

dem idyllischen Städtchen in Irland

adare GmbH (www.adare.de)

Gegründet 2002Firmensitz München (Einsatzorte: München, Ulm, Leonberg)

10 Mitarbeiter- 5 Festangestellte

- 5 assoziierte Freiberufler

Ingenieurdienstleistungen, spezialisiert auf- Protokollentwicklung

- Protokolltest – Testautomatisierung

im Mobilfunk, d.h. gegenwärtig Arbeit an 2.5 Generation (GPRS) und 3. Generation (UMTS)und mobile Applikationen Kunden: Rohde & Schwarz und Siemens

Markt Protokollentw. & Testautomatisierung

Wireless Know-how • GSM• GPRS• UMTS• Mobile Applications

Test Methods & Tools• TTCN, SDL, MSC• Rohde & Schwarz CRTU• Tektronix 1297• UBINETICS, …

SW-Development• Windows, .NET• Linux, Unix• Embedded OS• C++, Java, C#• Clearcase, UML, …

Protocol Knowledge• Air-Interface• Radio Access Network• NAS-Protocols• Application HTTP, SIP, …

Schwerpunkte!

Nachfrage kann anhaltend nicht befriedigt werdenMangel an (erfahrenen) Application Test EngineersAnforderungsprofil

Agenda

Was ist OMA?Wie arbeitet ein Standardisierungsgremium?Der Entwicklungsprozess für die Spezifikation (mobiler) AnwendungenBeispiele für mobile AnwendungenNoch mehr Spezifikationen: Tests zur Sicherstellung der InteroperabilitätProduktbeispiel Conformance-Testeradare GmbH – Protokollimplementierung & Testautomatisierung im Mobilfunk

Herzlichen Dank für Ihre Aufmerksamkeit

Open Mobile Alliance (OMA)(Nokia, Motorola, Ericsson, Unwired Planet) ... 5 n 5. Wiedervorlage...

Documents

Transcript of Open Mobile Alliance (OMA)(Nokia, Motorola, Ericsson, Unwired Planet) ... 5 n 5. Wiedervorlage...