Tổng quan giao thức EPCglobal

[thanhsang_truong]

Tác giả:
Trần Thị Thanh Nhã

Tổng quan giao thức EPCglobal

- Các giao thức của các vendor đều có chung một mục đích nhưng khác ở chỗ là không có client nào có thể liên lạc với thẻ mà không có adapter biên dịch giao thức của mỗi vendor. EPCglobal gần đưa ra một tiêu chuẩn mới cho các giao thức reader cho các chuẩn thẻ mới nhất. Chuẩn mới này sẽ cung cấp một tập giao thức cho tất cả các vendor thực thi và một phương pháp mở rộng giao thức cho các tính năng cụ thể của từng vendor. EPCglobal định nghĩa giao thức Reader dưới dạng 3 lớp như hình 4-4.

http://usera.imagecave.com/98765/TTTN_hinh57.jpg
- Trong đó:

• MTB (Message Transport Binding): encapsulate các lớp Messaging và Transport và đưa ra giao diện cho lớp Reader.
• Lớp Reader: định nghĩa nội dung và định dạng của thông điệp được gửi giữa reader với máy chủ. Lớp này tương đương 2 lớp Presentation và Application của mô hình OSI. Giao thức cho phép lớp này dùng nhiều MTB, nhưng thông thường chỉ sử dụng một MTB. Reader chỉ có thể có một conversation với một máy chủ.
• Lớp Messaging: quản lý kết nối, security, đóng gói các lệnh của máy chủ, các đáp ứng và thông báo của reader. Việc mã hóa, xác thực hoặc quản lý phiên xảy ra ở đây. Lớp này mô tả phương thức bắt đầu, kết thúc conversation giữa reader với máy chủ, định nghĩa dạng frame. Lớp này tương đương lớp Session của mô hình OSI.
• Lớp Transport: là lớp thấp nhất, nó mô tả các dịch vụ từ OS hoặc phần cứng hỗ trợ mạng. Nó tương ứng với các lớp Physical, Data Link, Network của mô hình OSI.
1. Lớp Reader:
- Gồm 4 hệ thống phụ: Read, Event, Output, Communication. Hình 4-5 trình bày các lớp con này.

http://usera.imagecave.com/98765/TTTN_hinh58.jpg

1.1 Hệ thống phụ Read:
- Đọc thẻ và cung cấp thông tin cho hệ thống phụ Event. Hình 4-6 trình bày ba giai đoạn trong hệ thống này.

http://usera.imagecave.com/98765/TTTN_hinh59.jpg
- Trong đó:


Source: đọc ID của thẻ, source có thể là một anten hoặc một nhóm anten hoặc một checkout scanner đọc mã vạch. Khi theo dõi nguồn đọc và chuyển thông tin này cho các giai đoạn tiếp theo thì giao thức cho phép hệ thống phụ Event, Output và máy chủ thực hiện các quyết định dựa trên nguồn đọc này.
Data Acquisition: điều hoà thời gian đọc. Ba tham số ảnh hưởng việc làm này là: chu kỳ nhiệm vụ (duty cycle), số chu kỳ đọc trên một trigger, thời gian chờ đọc (read timeout). Chu kỳ nhiệm vụ xác định xem reader sẽ bắt đầu việc đọc có thường hay không. Mỗi khi bắt đầu thì số chu kỳ đọc xác định reader sẽ đọc bao nhiêu lần. Thời gian chờ xác định reader sẽ chờ bao lâu trước khi xác định không có thẻ nào có mặt.
Read Filtering: drop hoặc “filter out” việc đọc thẻ không khớp với mô hình do máy chủ thiết lập. Chẳng hạn mô hình có thể nói “Trình cho tôi mọi thẻ có filter type 2”
Dữ liệu rời ngăn xếp liên tục: giai đoạn Source cung cấp cho giai đoạn Data Acquisition, rồi lần lượt cung cấp cho giai đoạn Read Filtering. Vào cuối tiến trình này, giai đoạn Read Filtering sẽ cung cấp cho hệ thống phụ Event. Đối với hệ thống phụ Read, mỗi lần nó đọc một thẻ nó cứ như đang đọc thẻ lần đầu tiên. Hệ thống phụ này không biết sự khác nhau giữa một thẻ mới và một thẻ đã được nhận ở chu kỳ trước đó, sự nhận thức đúng đắn này phải được thực hiện dây chuyền bởi hệ thống con Event.


1.2 Hệ thống phụ Event:
- Chuyển đọc thẻ thành sự kiện có ý nghĩa. Hình 4-7 trình bày giai đoạn của hệ thống con Event.

http://usera.imagecave.com/98765/TTTN_hinh60.jpg
- Giai đoạn này chịu trách nhiệm áp dụng smooth filter (lọc nhẵn) dữ liệu để nhận ra sự khác biệt giữa một thẻ thiếu trong một vài lần đọc và một thẻ không có mặt lâu hơn. Hệ thống phụ Read sẽ báo cáo sự có mặt của thẻ mỗi khi nó được đọc. Giai đoạn Smoothing/Event Generation duy trì trạng thái theo thời gian vì vậy nó có thể so sánh việc đọc và chỉ đi tiếp sự kiện có ý nghĩa, chẳng hạn có một thẻ mới đến hoặc vắng thẻ đã được đọc trước đó. Nó sàng lọc dữ liệu do hệ thống phụ Read phát sinh để có thể quản lý tốt hơn. Nó cũng kiểm tra mối liên hệ giữa nguồn và ID để phân biệt giữa thẻ gần nguồn A và thẻ đã di chuyển đến nguồn B (mà có thể anten khác được gắn vào cùng reader). Thông tin này sẵn có cho máy chủ truy vấn nhưng điều này hiếm khi đựơc thực hiện. Các sự kiện do giai đoạn này phát sinh được gửi đến hệ thống phụ Output để được lọc và đặt vào các báo cáo gửi đến máy chủ.

(còn tiếp)

[thanhsang_truong]

1.3 Hệ thống phụ Output
- Quyết định dữ liệu nào reader sẽ báo cáo, buffer dữ liệu và gửi báo cáo đáp ứng một trigger do máy chủ thiết lập hoặc lúc máy chủ yêu cầu trực tiếp. Hình 4-8 trình bày các giai đoạn của hệ thống phụ Output.

http://usera.imagecave.com/98765/TTTN_hinh61.jpg
- Trong đó ba trạng thái của hệ thống phụ Output có ý nghĩa sau:

• Data Selector: áp dụng filter do máy chủ thiết lập trước đó và từ chối dữ liệu nào không phù hợp với filter đó. Giai đoạn này cũng xác định những trường nào sẽ được báo cáo. Để sử dụng cơ sở dữ liệu tương tự, mô hình filter thực hiện mệnh đề WHERE trong khi những lệnh khác do máy chủ phát có thể thiết lập các trường tương tự như việc SELECT trong truy vấn SQL.
• Report Buffer: giữ vị trí cho các sự kiện chưa được phát đến máy chủ. Các sự kiện được tập hợp thành một danh sách gọi là report. Máy chủ có thể yêu cầu các report này bằng cách poll reader, hoặc chúng được phát đến máy chủ qua kênh thông báo khi một vài trigger xảy ra. Các sự kiện luôn được xóa khỏi Report Buffer ngay khi chúng được phát đến máy chủ. Giao thức không chỉ rõ những gì sẽ xảy ra nếu reader hết năng lượng hoặc buffer đầy, nhưng trong hầu hết các thực thi thì buffer sẽ mất nội dung khi năng lượng không còn và buffer là bufer FIFO hoặc ring tức là nó loại các sự kiện cũ nhất để nhận các sự kiện mới mỗi khi nó bị tràn bộ nhớ
• Trigger thông báo: xác định khi nào gửi report cho máy chủ theo trigger đã được máy chủ thiết lập trước. Chẳng hạn, máy chủ yêu cầu nhận thông báo sau 2,000 mili giây.
Report: là danh sách các sự kiện với một tập các trường được máy chủ cấu hình cho mỗi sự kiện. Giao thức mô tả một danh sách các trường xuất hiện trong report nhưng yêu cầu reader vendor chỉ thực thi một phần nhỏ. Đây là một trong những chi tiết sẽ được thay đổi trong tương lai vì có nhiều trường bắt buộc và có các trường không bắt buộc mới thêm. Bảng 4-2 là cơ sở các trường bắt buộc có khả năng xuất hiện trong các đặc tả giao thức tương lai.

Bảng 4-2: Các trường report mà các reader phải hỗ trợ.
http://usera.imagecave.com/98765/TTTN_hinh62.jpg
- Bảng 4-3 trình bày một số trường không bắt buộc hữu ích nhất mà reader có thể hỗ trợ.

Bảng 4-3: Các trường không bắt buộc quan trọng.
http://usera.imagecave.com/98765/TTTN_hinh63.jpg
Trigger: giao thức reader định nghĩa một implicit trigger và hai explicit trigger.

- Implicit trigger: là một yêu cầu thông tin từ máy chủ qua kênh lệnh (các kênh đã được thảo luận ở phần trước “The Messaging Layer”). Có nghĩa là giai đoạn Data Acquisition sẽ thực hiện một chu kỳ đọc qua nguồn và sau đó chuyển dữ liệu qua các giai đoạn, đưa đến giai đoạn Report Buffer để phát đến máy chủ trong một đáp ứng trên kênh lệnh.
- Explicit trigger: Có hai loại explicit trigger:


• Read trigger: nó thực thi giai đoạn Data Acquisition như thực hiện lệnh READ máy chủ, nhưng dữ liệu được đệm trong Report Buffer.
• Notify trigger: gây ra report trong Report Buffer để phát đến máy chủ nhưng không gây ra việc đọc mới nào.
- Máy chủ cũng có thể tạo ra việc đọc bằng cách dùng trực tiếp một lệnh IssueReadTrigger. Nó tạo ra việc đọc chứ không tạo ra thông báo. Bảng 4-4 mô tả các loại trigger. Các trigger này có thể là Read hoặc Notify trigger.

Bảng 4-4: Các trigger.
http://usera.imagecave.com/98765/TTTN_hinh63.jpg

(còn tiếp)

[thanhsang_truong]

Tác giả:
Trần Thị Thanh Nhã

1.4 Hệ thống phụ Communication
- Thực thi MTB trên reader. Các báo cáo lưu trong giai đoạn Report Buffer được gửi cho hệ thống phụ Communication khi giai đoạn Notification Trigger thực thi. Giai đoạn MTB đóng gói và thông dịch dữ liệu trong trường report để tuân theo các yêu cầu của lớp Transport. Hình 4-9 trình bày giai đoạn chứa trong hệ thống phụ Communication.

http://usera.imagecave.com/98765/TTTN_hinh65.jpg
- Như đã nói ở trên, MTB đóng gói các lớp Messaging và Transport tương đương với đóng gói các lớp Physical, Data Link, Network và Session trong mô hình OSI. Nó làm cho giao diện liên lạc cho reader đơn giản hơn. Reader có thể thực thi bằng Bluetooth hoặc TCP/IP qua mạng Ethernet không dây 802.11b
2. Lớp Messaging:
- Lớp này cung cấp ba kênh thông điệp: một kênh lệnh, một kênh thông báo và một kênh báo động. Từ “kênh” trong trường hợp này cho biết một ống dẫn logic, riêng rẽ mà thông điệp từ lớp Reader có thể tràn qua. Mỗi kênh có một tập luật riêng và một mục đích riêng, xem hình 4-10.

http://usera.imagecave.com/98765/TTTN_hinh66.jpg
- Trong đó:

• Kênh điều khiển: kênh này chấp nhận các thông điệp đồng bộ dưới hình thức các request do máy chủ khởi tạo. Các request từ máy chủ đến reader và response cho các request này từ reader đến máy chủ di chuyển trên kênh này. Reader không bao giờ khởi tạo liên lạc qua kênh này.
• Kênh thông báo: reader gửi các thông điệp bất đồng bộ đến máy chủ. Máy chủ không bao giờ khởi tạo liên lạc qua kênh này. Reader có thể gửi observation hoặc cảnh báo đến máy chủ.
• Kênh báo động: reader gửi các thông điệp báo động bất đồng bộ đến máy chủ. Máy chủ không bao giờ khởi tạo liên lạc qua kênh này. Reader cũng có thể gửi thông tin giám sát đến máy chủ, ví dụ như báo động cho biết mất kết nối với anten.
3. Lớp Transport:
- Các MTB khác nhau đối với giao thức Reader vẫn chưa được xác định hoàn chỉnh. Các vendor cũng hỗ trợ các MTB không được xác định trong giao thức này nhưng cùng kênh và cùng thông điệp.

3.1 TCP MTB:
- “Simple TCP” MTB là một MTB rất nhỏ dùng TCP để truyền tải. MTB này chỉ rõ reader theo mặc định sẽ lắng nghe cổng 8080 cho đến khi máy chủ thực hiện kết nối. Mỗi khi máy chủ thiết lập kết nối, reader phải từ chối tất cả kết nối từ các máy chủ khác. Đối với những chuyên viên thiết kế thường làm việc với các ứng dụng dựa theo TCP khác thì hoạt động này kỳ lạ, nhưng nó là giới hạn của máy chủ trong giao thức reader trong việc liên lạc của reader.
- MTB này đóng khung các thông điệp lớp Reader với một header cho biết thông điệp này thuộc kênh nào, khung gồm cả header và payload tính theo octet. Hình 4-11 minh họa cấu trúc của khung.

http://usera.imagecave.com/98765/TTTN_hinh67.jpg
- Trong đó:

• Channel ID: trường này có thể là 2 đối với kênh điều khiển, hoặc 3 đối với kênh thông báo. ID cho kênh báo động hiện tại chưa được xác định.
• Length: trường này có một giá trị không xác định từ 5 đến 2,147,483,648.
• Payload: đây là thông điệp lớp Reader.
- Khung này được dùng cho các thông điệp từ reader đến máy chủ và từ máy chủ đến reader. Máy chủ tạo kết nối và gửi thông điệp HostGreeting đến reader. Khi phát hiện ra có kết nối, không chờ thông điệp HostGreeting reader cũng gửi thông điệp ReaderGreeting. Khi hai bên đã nhận được lời chào thì chúng bắt đầu xử lý thông điệp lớp Reader. ReaderGreeting, HostGreeting có chiều dài 5 octet, octet cuối có giá trị là 5. Octet đầu tiên của ReaderGreeting bằng 1, còn của HostGreeting bằng 2. Các octet khác bằng 0. Hình 4-12 trình bày cấu trúc của lời chào.

http://usera.imagecave.com/98765/TTTN_hinh68.jpg

[thanhsang_truong]

3.2 HTTP MTB
- HTTP MTB tạo một kết nối HTTP 1.1 giữa máy chủ và reader cho kênh lệnh và một kết nối riêng giữa máy chủ và reader cho kênh thông báo. Lưu ý điều này không vi phạm những yêu cầu của giao thức bởi vì mỗi kết nối này là giữa reader và máy chủ đơn.
- Reader lắng nghe ở port 80. Trong TCP MTB, reader nhận kết nối từ một máy chủ và từ chối bất kỳ kết nối nào sau đó từ máy chủ khác. HTTP không yêu cầu kết nối constant, máy chủ có thể dừng kết nối TCP và vẫn xem như nó đã kết nối với máy chủ này, vẫn giữ trạng thái nào đó và tránh kết nối từ các máy chủ khác. Mỗi khi kết nối được thiết lập, máy chủ bắt đầu gửi thông điệp lớp Reader. Không tương tự như lời chào của TCP MTB. Thông điệp được đóng khung thành các lệnh HTTP GET, PUT hoặc POST, thông điệp thực sự lớp Reader được mã hóa trong trường RequestUri của HTTP request. Reader đáp ứng bằng HTTP response, trường Status-Code được thiết lập cho biết thông điệp có phải là đáp ứng lệnh hay là một lỗi. Thay đổi phải dùng lệnh POST đặt các lệnh và đáp ứng vào một XML document.
4. Giao thức Simple Lightweight RFID Reader (SLRRP):
- SLRRP là một Internet-Draft (đồ án Internet) của IETF. Nhằm mục đích interoperate với cả reader ISO 18000 và EPC. SLRRP khác xa giao thức EPCglobal Reader, nhưng nó được xem là “work in progress” vì vậy ta thấy có một số nhất trí giữa hai chuẩn.
- Máy chủ trong SLRRP luôn là một RFID Reader Network Controller (RNC) thực thi vai trò máy chủ của giao thức và cung cấp một giao diện máy khách để kết nối đến các ứng dụng máy khách và middleware. Hình 4-13 trình bày phương thức RNC nằm giữa reader và RFID middleware hoặc máy khách ứng dụng

http://usera.imagecave.com/98765/TTTN_hinh69.jpg
- RNC thực thi giao thức SLRRP vì vậy máy khách middleware, máy khách ứng dụng có thể giao phó máy chủ đóng vai trò RNC và chỉ thực thi một giao thức truyền với RNC. Đồ án hiện tại về SLRRP không định nghĩa giao thức truyền giữa RNC và máy khách. Giao thức reader đến RNC của SLRRP chỉ hỗ trợ TCP transport và chỉ định nghĩa cách tiếp cận đồng bộ đối với các thông báo.