1. Near Field Communication -סמינר בתקשורת ומערכות מבוזרות-
מציגים: יהונתן שלו ושלמה שמש
החוג למדעי המחשב, מכללת הדסה, תשע''ה

2. מה זה NFC ?
NFC (Near Field Technology) היא טכנולוגיית תקשורת אלחוטית בתדר גבוה לטווח קצר.
NFC מיועד בעיקר למכשירים ניידים או מחשב כף יד.
תקשורת רדיו שנוצרת ע''י מגע בין שני מכשירים או קירוב שלהם בטווח של עד 10 ס''מ.
מאפשר טרנזקציות פשוטות, חילופי נתונים וחיבורים אלחוטיים בין שני מכשירים.
מאפשר תקשורת בין:
שני מכשירים אקטיביים
מכשיר אקטיבי ומכשיר פאסיבי.
NFC trademark
logo

3. תכונות
NFC הוא ההרחבה של טכנולוגיית RFID (Radio frequency identification) המשלבת את הממשק של כרטיס חכם וקורא לתוך מכשיר אחד משולב. שילוב זה מאפשר תקשורת דו-כיוונית בין מכשירים שונים שהתאפשרה בעבר בכיוון אחד בלבד.
עבודה בתחום תדר של 13.56MHz ברוחב פס של 14kHz.
מרחק העבודה עם אנטנות סטנדרטיות: עד 10 ס''מ.
 קצבי נתונים נתמכים: 106Kbit/s , 212Kbit/s ו- 424Kbit/s.
בזמן תקשורת בין שני מכשירים באמצעות NFC, מכשיר אחד חייב להיות קורא/כותב, והמכשיר השני חייב להכיל NFC tag.

4. NFC Reader
בד''כ מערכת מבוססת מעגלים משולבים המסוגלת לייצר תדרי רדיו של MHz המכילה רכיבים נוספים כמו מקודדים, מפענחים, אנטנה ו-FW שנועדה לשדר גלים לתג ולקרוא מידע בחזרה. הקורא פולט אותות RF ברציפות, ומקבל אותו אלו המתפרשים כנתונים.
An NFC Reader
(A Smartphone )

5. NFC Tag
מכשיר RFID משולב עם שבב זיכרון עשוי סיליקון המחובר לאנטנה חיצונית.
מכיוון שה-Tag נחשב לרכיב פאסיבי, אין לו מקור כוח משלו. הוא סופג חלק קטן מהאנרגיה הנפלטת ע''י בקורא (המכשיר האקטיבי) ומתחיל לשלוח מידע כאשר מספיק אנרגיה התקבלה מהצד השני.

6. פעולות של NFC: קיימים 2 מצבי תקשורת:
מצב פאסיבי: המכשיר היוזם מספק שדה כוח ומכשיר היעד שולח תשובות ע''י ויסות השדה הקיים. במצב זה, מכשיר היעד עשוי למשוך אליו מכוח ההפעלה של השדה האלקטרומגנטי שסופק ע''י יוזם הטרנזקציה.
מצב אקטיבי: גם היוזם וגם היעד מתקשים באמצעות יצירת שדה RF משלהם לסירוגין. מכשיר הממתין לנתונים ינוטרל משדה זה. במצב זה, שני המכשירים זקוקים לאספקת חשמל.
קיימים 2 מצבי תקשורת:

7. פעולות של NFC:
מכשירי NFC מתקשרים זה עם זה באמצעות אינדוקציית שדה מגנטי שבו שתי אנטנות בצורת לולאה נמצאות קרוב זו לזו.
הקורא מייצר ברציפות גלי RF בתדר 13.56MHz וממתין שיווצר ויסות של התדר. ויסות זה מצביע על הימצאות של Tag קרוב שמשדר לקורא.

8. השוואה מול טכנולוגיות קיימות אחרות:

9. מצבי פעולה של מכשירי NFC:
מצב קורא/כותב
מכשיר NFC מסוגל לקרוא סוגי תגי NFC שונים כמו תג המוטבע על פוסטר NFC חכם.
מצב Peer-to-Peer
שני מכשירי NFC המחליפים נתונים ביניהם. למשל, אפשר להחליף מידע כמו כרטיסי ביקור וירטואליים, תמונות, מסמכים ועוד.
מצב מדמה כרטיס
מכשיר NFC שנראה כמו smart card רגיל עבור קורא חיצוני. מאפשר תשלומים ללא מגע וכרטוס על ידי מכשיר NFC מבלי לשנות את התשתיות הקיימות בשוק כיום.

10. מפרטים: פורום ה-NFC פרסם מפרטים שונים עבור NFC, ביניהם: מטרה מפרט
NFC Data Exchange Format (NDEF)
מציין כללים לבניית סוגי redord-ים המשמשים להרכבת ההודעות.
Record Type Definition (RTD)
פרוטוקול נתונים לתמיכה בתקשורת peer-to-peer בין שני מכשירים התומכים ב-NFC.
Logical Link Control Protocol (LLCP)
מגדיר איך ליצור חיבור תוך שימוש בטכנולוגיות תקשורת אלחוטיות אחרות.
Connection Handover
מאפשר יכולת פעולה הדדית בין tag-ים לבין התקני NFC.
Operations Specifications for Four Tag Types (1/2/3/4)

11. יתרונות של NFC: NFC מספק מגוון רחב של יתרונות לצרכנים ולעסקים, כגון:
פתיחות טכנולוגית: NFC מאפשר התקנה מהירה ופשוטה של טכנולוגיות אלחוטיות כמו Wi-Fi, Bluetooth ועוד.
מוצר מאובטח: שידורי NFC נחשבים למאובטחים מאוד בשל העובדה שהם מתבצעים בטווח קצר.
יכולת פעולה הדדית" NFC עובד עם טכנולוגיות כרטיסים קיימות, למשל smart-card.
פתיחות לאבטחה: NFC מכיל תמיכה מובנית יישומים מאובטחים.

12. אפליקציות NFC:

13. אפליקציות NFC:
פוסטר חכם:
אובייקט המכיל תג NFC אחד או יותר הניתן לקריאה (מודבר או מוטבע) המכיל הודעות NDEF המאוחסנות בו.
כל תג נקרא כאשר מכשיר NFC נמצא קרוב מספיק.
יכול להיות לוח מודעות, תג לביש, עיתון או אובייקט תלת ממדי אחר כלשהו.

14. אפליקציות NFC: תשלום חכם: טלפון בעל NFC יפתח את אפליקציית הארנק.
הארנק יציג את עלות המוצר כאשר המשתמש יבחר את המוצר.
לפני התשלום, הארנק יציג למשתמש את כל אמצעי התשלום הקיימים עבורו.
הלקוח יבחר את אמצעי התשלום הרצוי.
האפליקציה תציג דף אישור לתשלום.
הארנק יתחבר לרשת המוכרת לשם אישור והצגת מידע המעקב.

15. אפליקציות NFC:
Peer-to-peer
העברת חיבור: החלפת הגדרות המידע ע''י קישור NFC לצורך הקמת חיבור בקלות. (למשל Wi-Fi, Bluetooth) ולקבלת המידע המשותף בחיבור זה. חיבור יכול להתבצע בין מכשירי NFC בלבד.
אם כמות המידע קטנה, (עד 1kb) אפשר להשתמש ב-NFC עצמו כדי להעביר את הנתונים במקום לייצר תשתית. (למשל בכרטיסי ביקור, אנשי קשר וכו')
רכיבי PC
מכשירים בתוך הרכב
מערכות בידור ביתיות
אוזניות
מצלמות ומדפסות
הגדרת מודם WLAN מאובטח
Speakers (touch to connect)
Smart Tags

16. אפליקציות NFC: שימושים נוספים של פוסטרים בעלי NFC smart-card:
ניהול נכסים – קריאת כמות המלאי ע''י תגים חכמים.
גישה – וידוא גיש מאובטחת לשטח בניין עבור אנשים עם מכשיר NFC וקורא אלחוטי מתאים בלבד.
חניה – שימוש ב-NFC לאימות כניסה לחניה ולשמירת תיעוד הכניסות.
דיווח מרחוק של עובדים – עובדים מרחוב המאשרים סיום עבודה או ביקור במקומות.
מפות- מפת פוסטר NFC אינטראקטיבית המאפשרת למשתמש להוריד את המפה, לקבל מידע נוסף על שירותים רלוונטיים וכו'.
לוח אירועים – הורדת כרטיסים או קופונים לאירועים, קבלת מידע ועוד.
NFC Parking >>
<< Security Gate

17. NDEF(NFC Data Exchange Format)
כל הודעת NDEF מכילה NDEF record אחד או יותר, שכל אחד מכיל מידע מסוג כלשהו, בגודל של עד 2 בחזקת 32 פחות 1.
ניתן לשרשר Record-ים על מנת ליצור מטעני מידע גדולים יותר.
כל NDEF record מכיל 3 פרמטרים: אורך המידע, סוג המידע (כל סוג ניתן לאחסון. סוג המידע נשמר בצורת TNF) ומזהה המידע (ID = URI/MIME).

18. NDEF
מבנה הודעת NDEF:
ההודעה מורכבת מrecord אחד או יותר. הrecord הראשון בהודעה מסומן ע''י דגל MB(message begin) שערכו 1, והאחרון מסומן ע''י הדגל MB(message end) שערכו 1. אורך הודעה מינימלי הוא record אחד שבו MB=ME=1. אין הגבלה על גודל ההודעה.
מבנה ההודעה:
סדר האינדקסים של הrecordים נקבעים ע''י הסדר שבו המידע הוכנס להודעה (תלוי אפליקציה), והם לא נשמרים כחלק מהrecord-ים עצמם.
Record הוא היחידה שנושאת את מטען המידע (payload) בהודעת הNDEF. כל payload מתואר ע''י קבוצת הפרמטרים שלו.
NDEF Message
R1 MB=1 … Rr Rs
Rt ME=1

19. NDEF
נתח record:
נושא נתחים של payload-ים. נתחי payload משמשים לחלוקת כמות גדולה של מידע לחלקים קטנים יותר והכנסה שלהם להודעות NDEF.
כל נתח payload מקודד כרצף של נתחי recordים:
הראשון הוא ההתחלתי שבו הדגל CF = 1 (chunk flag). סוג המידע חייב להיות זהה לסוג המידע המוחזק ב payload שאותו הוא נושא, בלי קשר לאורך ההודעה.
אפס או יותר נתחים אמצעיים, שבכל אחד הדגל CF = 1, סוג המידע חייב להיות זהה לסוג המידע של הנתח הראשון ואורך המידע מוגדר להיות אורך המידע השמור ב payload שאותו הוא נושא.
הנתח המסיים, שבו CF=0, וע''י כך מציין שסוג המידע זהה לנתחים הקודמים. אורך המידע הוא כאורך ה payload המסיים.

20. NDEF נתח record: Payload מכיל את השדות: אורך, סוג ו-ID.
המידע הנשמר בהודעה מגיע כרצף של אוקטטים כאשר כל אוקטט מיוצג בשיטת big-endian. (האוקטט היותר משמעותי ראשון).

21. NDEF
מבנה NDEF record:
כל record הוא בעל אורך משתנה ומבנה קבוע המכיל את הדגלים הבאים:
MB: בית 1 המשמש כדגל לסימון תחילת ההודעה.
ME: בית 1 המשמש כדגל לסימון סוף ההודעה.
CF: בית 1 המשמש כדגל לסיון שזהו הנתח הראשון או האמצעי של מטען מחולק.
SR(short record): בית 1 המשמש כדגל האומר שאורך המטען נשמר באוקטט יחיד (ולא יותר).
SR=0
SR=1
header

22. NDEF
מבנה NDEF record:
IL: בית 1 המשמש כדגל שאומר שאורך השדה ID_length הוא אוקטט יחיד.
TNF (Type Name Format) 3 בתים לציון פורמט סוג המידע שבו משתמשים:

23. NDEF
מבנה NDEF record:
Type_length: unsigned 8-bit שמציין את כמות האוקטטים הנמצאים בשימוש להחזקת השדה TYPE.
ID_length: unsigned 8-bit שמציין את כמות האוקטטים הנמצאים בשימוש להחזקת השדה ID. ייתכן שהאורך הוא 0 ואז השדה ID מושמט מ-NDEF record זה.
Payload_length: unsigned int שמציין את כמות האוקטטים הנמצאים בשימוש להחזקת השדה PAYLOAD. אורך שדה זה נקבע ע''י SR_FLAG.
TYPE: שדה שמציין את סוג המידע שנשמר בrecord. ערך השדה חייב להיות תואם לערך ה-TNF ששייך לו.
ID: מכיל כתובת URI. הייחודיות הדרושה ל-id של ההודעה מובטחת ע''י שולח הודעה. לנתחי record אמצעיים וסופיים אין שדה ID, ושדה זה לא חייב להתקיים.
PAYLOAD: השדה שמכיל את תוכן ההודעה שנשלחה.

24. פרוטוקול SNEP
SNEP=Simple NDEF Exchange Protocol
פרוטוקול מסוג בקשה/תגובה שבו לקוח SNEP שולח בקשה לשרת SNEP וממתין לתגובה ממנו. מטרת הפרוטוקול היא להחליף הודעות NDEF.
הבקשה מגיעה בצורת טופס המכיל את השדות: גירסת הפרוטוקול, מתודת בקשה, אורך המידע באוקטטים והמידע עצמו.
השרת מבצע את הבקשה המתוארת ע''י המתודה על המידע שהתקבל ומחזיר תשובה ללקוח.
התשובה מכילה את השדות: גירסת הפרוטוקול, ערך החזרה של המתודה (הצלחה/כישלון), אורך שדה המידע באוקטטים ואת המידע המוחזר.

25. פרוטוקול SNEP
אם גודל הבקשה עובר את הקיבולת של יחידת שירות אחת הנמצאת שכבה אחת מתחת לפרוטוקול ההעברה, הודעת הSNEP תועבר בחלקים (פרגמנטים). הפרגמנטים ייבנו ע''י חזרה על הסרה והעברה של מספר תתי סדרות של אוקטטים מתוך ההודעה השלמה. על מנת שמקבל ההודעה ידע כמה אוקטטים עליו לקבל, הפרגמנט הראשון יכלול לפחות את הheader של הודעת הSNEP.
מקבל ההודעה המחולקת (לאחר קבלה של הפרגמנט הראשון) ידווח לשולח ההודעה האם הוא מסוגל לקבל את הכמות שצוינה בפרגמנט הראשון. שאר הפרגמנטים יישלחו רק אם השולח מקבל הודעת continue.
ניתן להעביר הודעה בחלקים גם אם מקבל ההודעה מסוגל לקבל את כל ההודעה בשלמותה.

26. פרוטוקול SNEP
אם מקבל ההודעה לא תומך בגירסת הפרוטוקול של ההודעה שקיבל, הוא יתייחס אל ההודעה כאל הודעה שנגמרה. (לאחר שקיבל את הפרגמנט הראשון). אחרת, המקבל יבדוק האם ההודעה חולקה בצד השולח ע''י הערכה של אורך ההודעה שהתקבלה מול אורך שדה המידע בכותר. הודעת SNEP תחולק אם לא כל האוקטטים בשדה המידע התקבלו ביחידת השירות הראשונה.

27. פרוטוקול SNEP
תגובתו של שרת שלא תומך בגירסת הפרוטוקול תהיה unsupported version. אם לקוח SNEP לא מכיר את גירסת הפרוטוקול של התגובה שנשלחה בחזרה מהשרת, אזי המשך התקשורת לא יתאפשר והטרנזקציה תופסק.
אם ההודעה נשלחה בפעם הראשונה בשלמותה (ללא צורך בחלוקה), הצד המקבל לא יישלח הודעת continue אלא את התגובה הסופית.

28. פרוטוקול SNEP דוגמה לבקשת GET: דוגמה לבקשת PUT:

29. פרוטוקול SNEP
העברת הודעות:
LLCP= Logical Link Control Protocol
LLCP מספק שירות תעבורה שהוא connection-oriented עם העברה סדורה ומובטחת של יחידות מידע שכל אחת תכיל לפחות 128 אוקטטים.
האפשרות של ריבוי חיבורי datalink נתמכת ע''י LLCP.
הודעות SNEP מועברות על קישור נתונים של LLCP באמצעות שירות הLLCP.
שרת SNEP פעיל ימתין לבקשות התחברות על שירות נקודת גישה (ACCESS POINT) של LLC. הכתובת של נקודת גישה זו מצויינת בבקשת ההתחברות שנשלחת מהלקוח. ברגע שחיבור datalink מוקם, הלקוח יכול לשלוח רק בקשות SNEP, והשרת יכול להחזיר רק הודעות תגובה על חיבור ה datalink.
לבסוף, הלקוח סוגר את החיבור כשהשיחה מסתיימת.

30. הודעות SNEP:
הודעות SNEP מורכבות מבקשות של הלקוח לשרת ותגובות מהשרת ללקוח.
הודעות בקשה:
הודעת בקשה נשלחת מהלקוח לשרת על מנת לבצע מתודה ספציפית על השרת.
ההודעה מכילה 4 שדות: גירסה, קוד בקשה, אורך ההודעה ותוכן ההודעה.

31. הודעות SNEP:
הודעות בקשה:
Version: גירסת פורמט ההודעה. מציין את פורמט ההודעה ואת יכולת השולח להבין הודעות עתידיות. הגירסה היא אוקטט יחיד שמייצג מבנה של 2 4-bit unsigned integers. 4 הביטים היותר משמעותיים מציינים את הגירסה באופן כללי ו-4 הביטים הפחות משמעותיים מציינים את הגירסה הספציפית.

32. הודעות SNEP:
הודעות בקשה:
Request: מכיל את הפעולה המבוקשת שתתבצע ע''י השרת. זהו אוקטט יחיד שמייצג 8-bit unsigned integer. ערכים אפשריים:

33. הודעות SNEP:
הודעות בקשה:
Length: מכיל את גודל שדה תוכן ההודעה באוקטטים. מיוצג באמצעות 4 אוקטטים שמייצגים 32-bit unsigned integer.
Information: תוכן ההודעה. תלוי בערך שדה הבקשה. שדה זה מושמט אם שדה גודל ההודעה מכיל את הערך 0.

34. הודעות SNEP:
הודעות תגובה:
הודעת תגובה נשלחת מהשרת ללקוח על מנת להעביר את תוצאות הריצה על המתודה שנשלחה כבקשה מהלקוח.
ההודעה מכילה 4 שדות: גירסה, קוד תגובה, אורך ההודעה ותוכן ההודעה.

35. הודעות SNEP:
הודעות תגובה:
Version: מציין את פורמט ההודעה ואת יכולת השולח להבין הודעות עתידיות. הגירסה היא אוקטט יחיד שמייצג מבנה של 2 4-bit unsigned integers. 4 הביטים היותר משמעותיים מציינים את הגירסה באופן כללי ו-4 הביטים הפחות משמעותיים מציינים את הגירסה הספציפית.

36. הודעות SNEP:
הודעות תגובה:
Response: מכיל את תוצאת ניסיון ההבנה של השרת את בקשת הלקוח ובמקרה של הצלחה-גם את תוצאות הבקשה. מדובר באוקטט יחיד שמייצג 8-bit unsigned integer. ערכים אפשריים:

37. הודעות SNEP:
הודעות תגובה:
Length: מכיל את גודל שדה תוכן ההודעה באוקטטים. מיוצג באמצעות 4 אוקטטים שמייצגים 32-bit unsigned integer.
Information: תוכן ההודעה. תלוי בערך שדה הבקשה. שדה זה מושמט אם שדה גודל ההודעה מכיל את הערך 0.

38. הודעות SNEP:
כל הודעת בקשה בפרוטוקול SNEP מכילה אחד מקודי הבקשה הבאים:
קודי בקשה:
Continue: הלקוח מבקש שהשרת ישלח את שאר הפרגמנטים של הודעת התגובה. הלקוח מזהה את היכולת שלו לקבל את שאר הפרגמנטים ולהרכיב אותם בהצלחה לכדי הודעתSNEP שלמה.
Get: הלקוח מבקש שהשרת יחזיר הודעת NDEF שתועבר עם הבקשה. שדה תוכן ההודעה של הבקשה יכיל 32-bit unsigned int שערכו יהיה האורך המירבי של הודעת NDEF שהלקוח יכול לקבל בתגובה, ולאחר 32 הביטים שרשור של הודעת NDEF יחידה שמזהה את המשאבים לאיחזור. מבנה ההודעה:

39. הודעות SNEP:
קודי בקשה:
Acceptable Length Field: מכיל את האורך המקסימלי (באוקטטים) של שדה תוכן המידע שניתן לקבל בהודעת התגובה של השרת. מיוצג ע''י 4 אוקטטים שהם 32-bit unsigned int.
PUT: הלקוח מבקש שהשרת יקבל את הודעת הNDEF המועברת עם הבקשה. שדה תוכן ההודעה יכיל הודעת NDEF יחידה. מבנה ההודעה:

40. הודעות SNEP:
קודי בקשה:
Reject: הלקוח לא יכול לקבל את שאר הפרגמנטים של הודעת התגובה של הSNEP המחולקת. הלקוח לא מצפה לטפל בפרגמנטים נוספים בהודעה הנוכחית, וקבלת פרגמנטים נוספים עלולה לאלץ את הלקוח לסגור את קישור הנתונים. קוד בקשה זה יכול להישלח רק אחרי קבלה של הפרגמנט הראשון בהודעת הSNEP המחולקת. בהודעה עם בקשה זו, לא יהיה שדה תוכן מידע.

41. הודעות SNEP:
קודי תגובה:
Continue: השרת קיבל את הפרגמנט הראשון של הודעת הSNEP המחולקת והוא מסוגל לקבל את שא הפרגמנטים. השרת מזהה את היכולת שלו לקבל את שאר הפרגמנטים ולהרכיב אותם בהצלחה לכדי הודעתSNEP שלמה.
:Success הבקשה הצליחה. המידע שהוחזר עם התגובה תלוי בקוד הבקשה שהועבר בהודעת הבקשה:
א. GET: תוכן ההודעה יכיל הודעת NDEF.
ב. PUT: תוכן ההודעה לא יוצג.
Not Found: השרת לא מצא שום דבר שתואם את הבקשה. תוכן ההודעה לא יועבר עם התגובה במקרה זה.

42. הודעות SNEP:
קודי תגובה:
Excess Data: השרת לא מצא משאב שתואם את הבקשה, אבל החזרה של התוצאה עלולה לעבור את גודל ההודעה האפשרי שהלקוח יכול לקבל כתגובה. תוכן ההודעה לא יכלל במקרה זה.
Bad Request: הבקשה לא מובנת ע''י השרת בעקבות שגיאות סינטקס. תוכן ההודעה לא יכלל במקרה זה.
Not Implemented: השרת לא תומך בפונקציונליות שדרושה על מנת למלא את הבקשה. תגובה זו מתאימה כאשר השרת לא מזהה את קוד הבקשה. תוכן המידע לא יכלל.

43. הודעות SNEP:
קודי תגובה:
Reject: השרת לא יכול לקבל את שאר הפרגמנטים של הודעת הבקשה של הSNEP המחולקת. השרת לא מצפה לטפל בפרגמנטים נוספים בהודעה הנוכחית, וקבלת פרגמנטים נוספים עלולה לאלץ את השרת לסגור את קישור הנתונים. קוד תגובה זה יכול להישלח רק אחרי קבלה של הפרגמנט הראשון בהודעת הSNEP המחולקת. בהודעה עם בקשה זו, לא יהיה שדה תוכן מידע.

44. סיכום
מכשירים ניידים הם היעד העיקרי עבור NFC. למרות של-NFC יש את הטווח הקצר ביותר מבין טכנולוגיות תדרי הרדיו, הוא נחשב למהפכני בזכות יתרון האבטחה, התאימות, הממשק הידידותי למשתמש וכמות האפליקציות התומכות בו.