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