GS1/Oliot ALE and Next

Jun. 25, 2014
Auto-ID Labs, KAIST
http://autoidlab.kaist.ac.kr
GS1/Oliot Application Level
Events (ALE)
Janggwan Im
limg00n@kaist.ac.kr, http://oliot.org, http://autoidlab.kaist.ac.kr, http://resl.kaist.ac.kr, http://autoidlabs.org, http://gs1.org

© Auto-ID Lab Korea / KAIST
Slide 2
 Introduction
 Role of ALE
 5 APIs of ALE
 Oliot-fc Design
 Deployment
 Future Direction
Contents

Slide 3
 RFID readers report tag reads as follows
Introduction
Tag EPC #1234 is read at 3:00 PM
Too much Data !
Duplicate Data !
Data not of interest !

Slide 4
 Application Level Events (ALE) provides filtering and grouping
function for tags read
Role of ALE
ALEMiddleware
From 3:00 PM to 4:00 PM,
“Samsung Galaxy S”
EPC #1234,
EPC #1235,
EPC #1236
are read
from the Front Door
(Reader #5, Reader #6)
Please give me:
a report every 1 hour
from the reader at front door
only Samsung Galaxy S products (starts with #123)
Reader #5
Reader #6

Slide 5
 Application Level Events (ALE)
is an interface for filtering and
grouping of RFID tags
 A middleware implementing
ALE interface is called
filtering and collection (F&C)
middleware
 5 APIs of ALE
– Reading API
– Writing API
– Tag Memory API
– Logical Reader API
– Access Control API
Interactions of ALE in EPCglobal
Architecture Framework
Filtering & Collection
= ALE implementation
Capturing Application
= ALE Client

Slide 6
 ALE request of reading API is like this,
ALE Reading API
Please give me:
a report every 60 seconds
only Samsung Galaxy S products
Event Cycle
Logical Reader
Filtering & Grouping Pattern
urn : epc : pat : sgtin-96 : 3 . X . 123 . *
Filter Value
Company
Product
Serial Number
GS1 Key type
(Serialized GTIN in 96-bits format)
This is a pattern string

Slide 7
 Reading API
– define/undefine Event Cycle
– poll Event Cycle
– subscribe / unsubscribe Event Cycle
ALE Reading API
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:ECSpec xmlns:ns2="urn:epcglobal:ale:xsd:1">
<logicalReaders>
<logicalReader>FrontDoor</logicalReader>
</logicalReaders>
<boundarySpec>
<repeatPeriod unit="MS">60000</repeatPeriod>
<duration unit="MS">59500</duration>
<stableSetInterval unit="MS">0</stableSetInterval>
</boundarySpec>
<reportSpecs>
<reportSpec reportIfEmpty="false" reportOnlyOnChange="false">
<reportSet set="CURRENT"/>
<filterSpec>
<extension>
<filterList>
<filter>
<includeExclude>include</includeExclude>
<patList>
<pat>urn:epc:pat:sgtin-96:3.X.123.*</pat>
</patList>
<fieldspec>
<fieldname>epc</fieldname>
<datatype>EPC</datatype>
<format>epc-tag</format>
</fieldspec>
</filter>
</filterList>
</extension>
</filterSpec>
<output includeRawHex="false" includeRawDecimal="true“
includeEPC="false" includeTag="true" includeCount="true“/>
</reportSpec>
</reportSpecs>
</ns2:ECSpec>

Slide 8
 Define a logical reader
– E.g. “Front Door”
 Several physical readers are abstracted to a
logical reader
 Insulates applications from device details
 Elevates level of abstraction for application
writers
ALE Logical Reader API
Reader #5
Reader #6
“Front Door”
ALE Implementation
Reader Reader New Reader !
ALE Client
Reader Reader
ALE Client
ALE Implementation
New Reader !
Logical Reader Abstraction

Slide 9
 Logical Reader API
– define / undefine Logical Reader
– assign / deassign Physical Readers to
Logical Reader
ALE Logical Reader API
<ns3:LRSpec xmlns:ns2="urn:epcglobal:ale:wsdl:1"
xmlns:ns3="urn:epcglobal:ale:xsd:1">
<isComposite>true</isComposite>
<readers>
<reader>Reader5</reader>
<reader>Reader6</reader>
</readers>
<properties>
<property>
<name>Description</name>
<value>Front Door</value>
</property>
</properties>
</ns3:LRSpec>

Slide 10
 Tag Memory API
– define / undefine TMSpec which is mappings of the information in tag view
into a logical field
ALE Tag Memory API
EPC 1 0
Reserved EPC TID User
Field “epc” field “Melt” field “Rotten”
Tag View
Logical field in ALE View
Bank0 Bank1 Bank2 Bank3
1 0

Slide 11
 Tag Memory API
– define / undefine TMSpec which
abstract the information in a tag other
than EPC
ALE Tag Memory API
<?xml version="1.0"?>
<ns2:TMFixedFieldListSpec
xmlns:ns2="urn:epcglobal:ale:xsd:1">
<fixedFields>
<fixedField>
<fieldname>melt</fieldname>
<bank>3</bank>
<length>1</length>
<offset>0</offset>
<defaultDatatype>uint</defaultDatatype>
<defaultFormat>decimal</defaultFormat>
</fixedField>
</fixedFields>
</ns2:TMFixedFieldListSpec>

Slide 12
 Writing API
– ALE request of writing API is like this,
 Possible Writing Operations
– READ, CHECK, INITIALIZE, ADD, WRITE, DELETE, PASSWORD, KILL,
LOCK
ALE Writing API
Please give me:
a report every 60 seconds
only Ice Cream products from x corp
after WRITE ‘melt’
Command Cycle
Logical Reader
Filtering & Grouping
Pattern
Writing Operation

Slide 13
 Writing API
– define/undefine Event Cycle
– poll Event Cycle
– subscribe / unsubscribe Event Cycle
ALE Writing API
<ns2:CCSpec xmlns:ns2="urn:epcglobal:ale:xsd:1">
<logicalReaders>
<logicalReader>FrontDoor</logicalReader>
</logicalReaders>
<boundarySpec>
<repeatPeriod unit="MS">20000</repeatPeriod>
<duration unit="MS">19000</duration>
<noNewTagsInterval unit="MS">0</noNewTagsInterval>
</boundarySpec>
<cmdSpecs>
<cmdSpec reportIfEmpty="false" name="cmd1">
<filterSpec>
<filterList>
<filter>
<includeExclude>INCLUDE</includeExclude>
<fieldspec>
<fieldname>@3.1.0</fieldname>
<datatype>uint</datatype>
<format>hex</format>
</fieldspec>
<patList>
<pat>*</pat>
</patList>
</filter>
</filterList>
</filterSpec>
<opSpecs>
<opSpec>
<opName>WW</opName>
<opType>WRITE</opType>
<fieldspec>
<fieldname>melt</fieldname>
<datatype>uint</datatype>
<format>hex</format>
</fieldspec>
<dataSpec>
<data>1</data>
</dataSpec>
</opSpec>
</opSpecs>
</cmdSpec>
</cmdSpecs>
</ns2:CCSpec>

Slide 14
 Access Control API
– Think of a membership, read/write permission in the web board
ALE Access Control API
admin
Super user
Associate
Member
Normal
Member
Reader Conf. Tag Read Tag Writing
user1
ALELR.define ALE.define ALECC.define
Client Identity
Role
Permission
Class/Method
user2

Slide 15
 Access Control API
– define / undefine Client Identity
– define / undefine Role
– define / undefine Permission
– assign / deassign Role to Client Identity
– assign / deassign Permission to Role
ALE Access Control API

Slide 16
 Oliot-fc is developed based on Fosstrak which is an open source ALE Implementation
– Fosstrak implemented only Reading and Logical Reader API, but Oliot-fc implemented full ALE interface
– Internally, Oliot-fc uses Spring framework and most functions are implemented as service components
Oliot-fc Design
Filtering
and
Collection
Event
Cycle
EC Report
Generator
Command
Cycle
CC Report
Generator
Symbolic
Field
Repo
Logical
Reader
Abstraction
Physical
Reader
Connection
SubscriberOutputChannel
Logical Reader
Physical Reader
Acceptor
LLRPAdaptor
External
Fortress
RBAC
Server
Logical Reader
Manager
HTTP/SOAP
Endpoint
ALE ALECC ALETM ALELR ALEAC
Access
Control
FortressRolebased
AccessController(RBAC)
RFID Reader

Slide 17
 Fc-commons
– The project for common classes which are used in both fc-server and
fc-client such as classes for web service, marshalling utils
 Fc-server
– The main project for filtering and collection server
– Spring framework based implementation
– Fortress RBAC based access control
 Fc-client
– The project for ALE client; including API call example, Swing-based ALE client
 Fc-webclient
– The project for web ALE client; Outcome is executed on a web container such as
Tomcat
Projects for Oliot-fc

Slide 18
 Oliot-fc Build & Deployment
– Oliot-fc is a Maven project
– Compiled binary is packaged to Web archive
file (.war)
– It can be deployed to the web container such
as Tomcat
– Oliot-fc is executed with the web container
when it runs
 Send ALE request to fc-server
– Compile with Maven
– APITest class of fc-client provides API test
codes for ALE interface
– Or, you can use fc-webclient with Tomcat
web container
Oliot-fc Deployment
Compiled fc-server
Web archive (.war)
Web Container
(Tomcat)
Compiled fc-webclient
Web archive (.war)
Web Container
(Tomcat)
Compiled fc-client
Java binaries
JRE

Slide 19
 For F&C cloud deployment, we developed load balancing, and
migration solution
 EPC Cloud Admin:
– Collect Load Information
– Predict Future Load
– Manage Data-flow Migration
Deployment onto Cloud

Slide 21
 STIS with BigData processing over IaaS Cloud
Our another ALE project: Smart Thing
Information Service (STIS) middleware
Jongwoo Sung, Tomas L. Sanchez, Daeyoung Kim, "EPC Sensor Network for RFID and WSN Integration Infrastructure",
Proceedings of the Fifth Annual IEEE International Conference on Pervasive Computing and Communications
Workshops(PerComW'07), New York, USA, March 19-23, 2007 (position paper, new one is coming)

Slide 22
CEP-based STIS Middleware
 STIS is an effort to integrate various sensor networks to EPCglobal
architecture framework
– E.g. Zigbee, 6LoWPAN CoAP, oBix
 We integrated them in the ALE middleware level using complex event
processing (CEP) technology
– Open source CEP engine ‘Esper’ is used
– Data from various devices is adapted for CEP
– Complex events are detected and notified to report generator according to the SQL-
like event processing language (EPL)
STIS Middleware Design
Report
Generator
RFID Device
Framework
6LoWPAN CoAP
Device Framework
Zigbee Device
Framework
Event Processing
Language (EPL)
Event
Notification
ALE Report
CEP Engine
EventAdaptation

Slide 23
 Complex Event Processing (CEP)
– an event processing concept that deals with the task of processing multiple real-time
events with the goal of identifying the meaningful events within the event cloud
– with event processing language (EPL) of CEP, we can process multi-level events as
follows for instance:
What we can do with CEP
RFID tag ReadTemp. Humidity
Poor management
Loss of commodity values
keep occurring for
tag.highTempThresholdTime
or tag.highHumidityThresholdTime
Product Sold
Decrement of inventory
RFID tag Read
tag.readerID =
point_of_sales_reader_ID
Good Management
keep occurring for
tag.periodOfCirculation
temp. <
tag.thresholdTemp
humidity <
tag.thresholdHumidity
and
temp. >
tag.thresholdTemp
humidity. >
tag.thresholdHumidity
or

Slide 24
 IoT6: IPv6 based SOA among smart thing components/app./service
 Demonstrated
– IoT Week 2012, Venice, Italy
– IoT 2012 conference, Wuxi, China
IoT6 Project: STIS, ONS, and IoT6
integration
ZigBee Sensor Nodes
Architecture for Smart Thing Information Service
ZigBee Gateway
RFID
Reader
FX7400
SNAIL Gateway
Each Room
1 RFID Reader & Antenna
5 tagged devices
2 SNAIL Sensor Nodes
2 ZigBee Sensor Nodes
Object Naming Service (ONS)
EPC Information Service(EPCIS)
Filtering and Collection (F&C)
2001:220:806:20::1
2001:220:806:22::1
SNAIL Sensor NodesTagged
device
2001:220:806:20::1143.248.106.220,125,131
2002:8ff8:6a89::8ff8:6a89
2002:8ff8:6a6c::8ff8:6a6c
2002:8ff8:6a87::8ff8:6a87
CoAP
LLRP
poll
LLRP Port: 5084
LLRP
poll
2
1
1. Lookup IP address of EPCIS
(DNS Protocol)
2. Query to EPCIS for EPC-
related data (SOAP over HTTP)
An IoT6 Client
application in Venice
A GUI of STIS
test-bed
24

Slide 25
 From the experience of STIS middleware, we will design a new sensor
data processing middleware
– ALE interface has not enough expressive power for filtering and grouping pattern of
sensor data (RFID-specific)
– Instead of adding features to Oliot-fc, we decided to design a new sensor data
processing middleware
– A new middleware will support various sensor interfaces and interoperate with other
IoT platforms
Future Direction: Design of Sensor Data
Processing Middleware
Passive Tags
(e.g., passive
tags, barcode)
Sensor & Actuator Networks
(e.g., ZigBee, 6LoWPAN, Mobile phone, BLE,
AllJoyn, lwM2M etc.)
Active Tags (e.g.,
Wireless ID and Sensor
Networks)
RFID Middleware
LLRP LLRP Sensor & actuator protocols Sensor & actuator protocols
Domain-specific capturing application
Domain-specific accessing applications
Sensor Interface
Sensor interface
EPC Information Service
(static and dynamic information)
ALE
Actuation Interface
Sensor & Actuator Middleware
Object
Name
Service
Discovery
Service
ZigBee
6LoWPAN/
CoAP
MQTT
Web
service-*
REST
Other
Comm.
RFID stream processing
Logical RFID
reader
Reader
Management
Sensor stream
processing
Sensor & actuator
Management
ID-Sensor stream
processing
New!

Slide 26
 Performance Optimization
– Currently, 2 threads are involved for each event cycle
– If # of ECSpecs are increased tremendously, this design causes much overhead
– We will redesign internal structure so that a stream is assigned to each reader set
– The stream can be shared among multiple event cycles
– A thread can also be shared among multiple report generators
Future Direction 2: Performance
Optimization for Oliot-fc
LRAdaptation
RG
EC
RG
RG
Reader Set based Stream

Slide 27
 Jongwoo Sung, Tomas L. Sanchez, Daeyoung Kim, "EPC Sensor
Network for RFID and WSN Integration Infrastructure", Proceedings of
the Fifth Annual IEEE International Conference on Pervasive Computing
and Communications Workshops(PerComW'07), New York, USA, March
19-23, 2007
 Weixin Wang, Jongwoo Sung, Daeyoung Kim, "Complex Event
Processing in EPC Sensor Network Middleware for Both RFID and WSN",
11th IEEE International Symposium on Object/component/service-
oriented Real-time distributed Computing (ISORC 2008), May 5-7,
Orlando, Florida, USA
 임장관, 성종우, 김대영, "RFID ALE미들웨어에서의 센서 네트워크 지원을 위한
인터페이스 확장과 Complex Event Processing", 한국통신학회 2009 하계
학회, 2009)
 이경태, 임장관, 성종우, 김성훈, 하민근, 김대영, "EPC Sensor Network 에서의
데이터 처리와 정보 공유를 위한 미들웨어" 한국정보과학회 추계 학술대회,
2010년 11월
Reference

Slide 28
 Any questions?
Thank you

GS1/Oliot ALE and Next

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Viewers also liked

Viewers also liked (20)

Similar to GS1/Oliot ALE and Next

Similar to GS1/Oliot ALE and Next (20)

More from Daeyoung Kim

More from Daeyoung Kim (20)

Recently uploaded

Recently uploaded (20)

GS1/Oliot ALE and Next