1 / 21

March 2009 San Diego, CA John Moring

March 2009 San Diego, CA John Moring . Action 02/09-07. Return to the Valley of the WAVE Architecture Diagram. Action item 02/09-07. 02/09-07. Provide, for Dot0 discussion, the relative placement of the 1609 parts in the 1609 architecture diagram. Discussion begun live in San Diego

ferguson
Download Presentation

March 2009 San Diego, CA John Moring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. March 2009San Diego, CAJohn Moring Action 02/09-07 Return to the Valley of the WAVE Architecture Diagram

  2. Action item 02/09-07 • 02/09-07. Provide, for Dot0 discussion, the relative placement of the 1609 parts in the 1609 architecture diagram. • Discussion begun live in San Diego • No consensus reached • These charts collect background material to facilitate ongoing discussion • Previously-approved 1609 figures • Proposed refinements • 802/802.11 models • Base ISO OSI model • ESTI ITS model • WG member proposals

  3. WAVE Representations [IEEE 1609.3-2007] These figures were agreed and published in IEEE 1609-2007

  4. Let’s agree on our objectives ... • Overheard at the coffee table (paraphrased) • This figure should provide a simplified view of the system that can be used to introduce the system • A confusing figure will be counter productive Objective 1: A single figure to represent WAVE protocol architecture Objective 2: Relate architectural elements to standards • May be a separate figure Objective 3: Illustrate SAPs/interfaces between architectural elements • May be separate figure or figures

  5. An observation and an opinion • Reference documents do not provide an exact guide for representing our system • We should not feel constrained by a need to match external documents – we should use whatever representation best fits our needs

  6. OSI Seven layer reference model and peer protocols [X.200] • No layer-specific management entities are recognized by X.200: • 8.3.3 Systems-management • 8.3.3.1 Systems-management relates to the management of OSI resources and their status across all layers of the OSI Reference Model…. • 8.3.3.2 The protocols for systems-management reside in the application-layer, and are handled by systems management-application-entities. • 8.3.4 Layer-management • 8.3.4.1 There are two aspects of layer-management. One of these is concerned with layer activities such as activation and error control. This aspect is implemented by the layer protocol to which it applies. • 8.3.4.2 The other aspect of layer-management is a subset of systems-management. The protocols for these activities reside within the Application Layer and are handled by systems-management-application-entities.

  7. Reference Model for end stations [IEEE 802-2001] The base 802 model identifies SAPs and Physical layer and MAC/LLC sublayers in the data plane.

  8. Reference Model with end-station management and security [IEEE 802-2001] 802 shows management embedded in the data plane (at least for LLC), but management information off to the side.

  9. IEEE 802 standards [IEEE 802-2001]

  10. 802.11 Reference Model [IEEE 802.11-2007] “Portion of the ISO/IEC basic reference model covered in this standard” • Notes: • 802.1X specifies “Port-Based Network Access Control” • MLME_PLME equals PLME_SAP SAP • This implies that MLME & PLME are in the data plane “In order to provide correct MAC operation, an SME is present within each STA. The SME is a layer independent entity that can be viewed as residing in a separate management plane or as residing “off to the side.” The exact functions of the SME are not specified in this standard, but in general this entity can be viewed as being responsible for such functions as the gathering of layer-dependent status from the various layer management entities (LMEs), and similarly setting the value of layer-specific parameters. SME would typically perform such functions on behalf of general system management entities and would implement standard management protocols.”

  11. Another 802 representation: WiMAX [IEEE 802.16-2004]

  12. Proposed ETSI Station Architecture • This is a general ITS station architectural depiction, developed in 2008 and proposed as a common representation for ITS work in ETSI, ISO, and IEEE. • I believe the IEEE 802.11p/1609 elements can be mapped into this representation, e.g., as shown by the dotted boxes.

  13. FSimon, 040108

  14. FSimon, 040502

  15. FSimon, 010407

  16. FSimon 1609.3, 090325

  17. FSimon 1609.4, 090325

  18. RRoy 090319

  19. JMoring, Feb 09 This is Moring’s update, published in 1609.3 d1.1. • Removed explicit indication of the MIB from WME • Removed "Multi-Channel Operation" from MAC • - Aligned the WME block with the 1609.3 data plane components (e.g., UDP/IP/LLC). It previously extended down to the bottom of the PHY, and MLME was shortened to allow WME to touch WAVE MAC. All functions of the WME occur at the Networking Service layer • - Added Security Services • - Changed "To Airlink" to "Air Interface", adopting the term used in 802.11

  20. 1609.2 Security Services Higher Layer Entities Higher Layer Entities 1609.11, et al. Higher Layer Entities 1609.3 WME WSMP UDP, TCP IPv6 LLC MLME MAC P802.11p PLME PHY Alternate representation of WAVE entities, showing standards Here Moring moves Security to another plane to better show that it is accessible by data, management, and Higher Layer entities. 1609.4

  21. Back to the Drawing Board!

More Related