4 3a Technical Scope SDO Technical Scope Principles

  • Slides: 4
Download presentation
[4. 3]a Technical Scope SDO Technical Scope Principles: • Avoid overlap with existing work

[4. 3]a Technical Scope SDO Technical Scope Principles: • Avoid overlap with existing work (e. g. , 3 GPPs) and focus on cooperative efforts • Prioritize work efforts based upon importance and work assignments • Maintain flexibility for inputs from verticals Overall Scope: • Service layer aspects with high level and detailed service architecture, in light of an access agnostic view of end-to-end services • Protocols/APIs/standard objects based on this architecture (open interfaces & protocols) • Security and privacy aspects • Interoperability, including test and conformance specifications • Charging aspects (charging data, not billing) • Identification and naming of devices and applications • Information models • Use cases and requirements (common set across verticals) Common terminal/module service layer interface or API are for further study. NOTE: Develop pictorial diagram as example of E 2 E service layer. M 2 MCons 02_27 1

[4. 3]a Technical Scope SDO ARIB/TTC ATIS Technical Scope Service aspects with high level

[4. 3]a Technical Scope SDO ARIB/TTC ATIS Technical Scope Service aspects with high level and detailed service architecture API specific to M 2 M service components Identification and naming of devices and applications in service level domain Interoperability including test specifications Informational models Security and privacy aspects Charging aspects (charging data, not billing) Service layer focus Harmonized use cases and requirements (common set across verticals) Common service layer architecture (including security aspects) Protocols/APIs/standard objects based on this architecture (open interfaces & protocols) Identify services required in lower layers (plus APIs and adaptation layer to lower layers) Testing specifications for above Conformance specifications NOT Address: - aspects outside the service layer (done in other SDOs/fora) (e. g. 3 GPP) (BBF = TBD) - Avoid device management fragmentation (e. g. OMA) - UICC aspects under existing SDOs (e. g. 3 GPP, ETSI) - Application layer aspects should be addressed by vertical segments and app-centric fora) M 2 MCons 02_27 tbd 2

[4. 3]b Technical Scope SDO Technical Scope CCSA End-to-end view with attention to service

[4. 3]b Technical Scope SDO Technical Scope CCSA End-to-end view with attention to service aspects - #2 thru #7 of CCSA lists seems to be same list as #2 thru #7 of ARIB/TTC list Terminal/module aspects (for cost and economies of scale benefits - analyze M 2 M related terminal/module requirements for categorization - consider inviting terminal/module vendors to join ETSI Service Layer and Application Layer with end-to-end view and access independence Requirements, architecture, protocols, interoperability testing Collaboration with wireline and wireless SDOs/fora for core and access network aspects Collaboration with vertical (domain specific) SDOs/fora NOT Address: - Specifications of M 2 M services and applications TIA Mission statement provided (open, non-telecom centric) (appendix with scope list) Service aspects High level and detailed level service architecture Specification of API to the M 2 M service components Identification and naming of devices and applications in service layer domain Interoperability (including test specifications) Information models Security and privacy aspects of M 2 M Charging aspects of M 2 M (charging data, not billing) 3

[4. 3]c Technical Scope SDO TTA Technical Scope Architectural framework Use cases and requirements

[4. 3]c Technical Scope SDO TTA Technical Scope Architectural framework Use cases and requirements Functional service entities and data model Identification and naming of devices and applications Authentication, authorization, accounting, charging Security and privacy Maintenance and management Interoperability and conformance testing API to M 2 M services components Embedded module design 4