SIBMA Protocol ( Brazilian System of Advanced Metering v1.0 - PowerPoint PPT Presentation

SIBMA Protocol ( Brazilian System of Advanced Metering v1.0 21/12/12) Application Architecture Claudio Shu Xiong Ng

Model • application protocol: standard, framework

SIBMA protocol • asynchronous • scalability • interoperability • technical requirements

Constrained Application Protocol (CoAP) • web transfer protocol • provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. • interfaces with HTTP

SIBMA protocol • Constrained Application Protocol(CoAP) • Common Information Model(CIM) • model => classes diagrams modeled on UML language • standard format to represent the structured resources: „Efficient XML Interchange(EXI)“

Interaction

Interaction

Interaction

Interaction

Interaction

Interactions • a couple request-response • Sintax, semantic and processing from the messages : follow the CoAP protocol • CoAP: transportation by not-trusted datagrams and not-oriented to the connection

Interactions • User Datagram Protocol(UDP) • independent in relation to others • atomic

Interactions • SIBMA‘s device: embedded system • Devices: • must discard the datagrams that don‘t respect the correct checksum from the UDP‘s head • can be simultaneously client and server from differents interactions • must have only one socket to communicate with another device

Messages • Requisition starts an interaction • Response ends an interaction • Each requisition has only one response • CoAP‘s requirements • Devices must support the confirmation of messages, including asynchronous where the scalability is relevant

Messages Recommendations: • – Confirmation of request: asynchronous response – Replier: synchronous response(by piggybacking), unless „time out“ – Server: mustn‘t request a response – The receipt of response is enough – When a response is received with a confirmation request, the same must be soon as possible confirmed and quarantine stabilized to the associated token The token and time out: configurable • Sometimes the responses can‘t be received ➠ retries can • be sended and consider this only one interaction

Fragmentation • application layer • Blocks interactions as clients/servers • Implementations support all blocks with a maximum length of 1024 bytes • when the maximum length of the block is higher than 1024 bytes

Fragmentation • Less than 1024 bytes ➠ not necessary but when it‘s used can have some benefits • When the client receives a message CoAP and its buffer is unable to process it ➠ a new request with a smaller block • Request entity too large response ➠ reduce the block size

Resources ● class diagrams(UML) ● have attributes, which values can change ● uniform interface: create, update, read and delete resources ● structured or not-structured ● single or compound

Collections • group of resources • resources with the same structure • SIBMA‘s interaction can manipulate simultaneously many resources of the same collection

Attributes • Are data fields that represent characteristics of one determined resource at a particular time • Classification: – Read/write or read only – Obligatory or optional

Content • payload of a CoAP's message • Each SiBMA resource content is specified by a XML schema (XSD). • Before be sent by a cliente or processed by a server, XML contents are always validated from XSD.

Identifiers ■ based on the Uniform Resource Identifier (URI) ■ uri = 1*segment ■ segment = “/” (tag / value) ■ tag = 1*ALPHA *HEXDIG ■ value = 1*HEXDIG *(“-” 1*HEXDIG)

Scope ■ scope = uri *scope-segment ■ scope-segment = “/” (scope-tag / scope- value) ■ scope-tag = 1*ALPHA *HEXDIG ■ scope-value = 1*HEXDIG *(“-” 1*HEXDIG)

Methods • POST • GET • PUT • DELETE

Security ■ Security session ■ Digest access authentication ■ EndDeviceID(unique identifier, 8 bytes)

Templates ■ show the valid syntax