CS434/534: Topics in Networked (Networking) Systems Mobile Networking System: Making Connections: Cloud; NFC Yang (Richard) Yang Computer Science Department.

CS434/534: Topics in Networked (Networking) Systems Mobile Networking System: Making Connections: Cloud; NFC Yang (Richard) Yang Computer Science Department Yale University 208A Watson

Admin. Project planning Checkpoint II: Apr. 20 Checkpoint III: Apr. 27
Initial design; feedback from instructor/TF Checkpoint III: Apr. 27 Design refined; key components details Final due: May 4 No more than 6 page write up

Recap: Making Bluetooth Conn.
Underlying technology Nodes form piconet: one master and upto 7 slaves A node makes itself discoverable The slaves discover the master and follow the pseudorandom jumping sequence of the master Higher-layer introduces profiles to provide specific functions Android Bluetooth software API Configuration: Announce Bluetooth permission Intent to request systems service: turn on BT, become discoverable Obtaining bonded devices: query, register broadcast receiver Connection: Server: mBluetoothAdapter.listenUsingRfcommWithServiceRecord(SNAME, MY_UUID); … A piconet

Recap: Making WiFi Direct Conn.

WiFi Direct Software Framework (Android)
Setup permission in Manifest Create IntentFilter and Broadcast Receiver to obtain related updates intentFilter.addAction WIFI_P2P_STATE_CHANGED_ACTION WIFI_P2P_PEERS_CHANGED_ACTION WIFI_P2P_CONNECTION_CHANGED_ACTION WIFI_P2P_THIS_DEVICE_CHANGED_ACTION /** register the BroadcastReceiver with the intent values to be matched */ public void onResume() { super.onResume(); receiver = new WiFiDirectBroadcastReceiver(mManager, mChannel, this); registerReceiver(receiver, intentFilter); } public void onPause() { super.onPause(); unregisterReceiver(receiver); } Initiate action Call discoverPeers mManager.discoverPeers(mChannel, new WifiP2pManager.ActionListener() { … Call connect Create group

Recap: Making Cellular Conn.
Issue: Given the large overhead to set up radio resources, UMTS implements radio resource control (RRC) state machine on mobile devices How to best design this framework (or more generally power management framework for wireless) is not fully solved. Channel Radio Power IDLE Not allocated Almost zero CELL_FACH Shared, Low Speed Low CELL_DCH Dedicated, High Speed High

Outline Admin Android Platform overview Basic concepts
Inter-thread: execution model with multiple threads Inter-process: component composition Inter-machine: network-wise composition Service discovery Make connections Bluetooth WiFi Direct Cellular Mobile cloud

Discussion: Mobile Cloud Connections
What are some reasons (services) you can think of involving mobile-cloud connections?

Example Mobile Cloud Services
Push notification service Storage and sync, e.g., Syncing and storage service (iCloud) Compute and split architecture, e.g., Siri, Amazon silk (

Inter-thread: execution model with multiple threads Inter-process: component composition Inter-machine: network-wise composition Service discovery Make connections Bluetooth WiFi Direct Cellular Mobile cloud Cloud push notification

Setting: Data Refresh A typical design pattern is that a device updates/receives data (e.g., news) from publisher A first solution is mobile pull, but this can create large overhead

Shared Push Service A single persistent connection from device to a cloud push service provider Multiple application providers push to the service provider Service provider pushes to a device using the persistent connection Two examples Apple Push Notification Service (APNS) Firebase (Google) Cloud Messaging (FCM/GCM)

Design Requirements of a Shared Push Service
Security/Authorization Do not allow arbitrary app to push to a device Scalability A large scale system may have millions of clients Fault tolerance Client/device, push servers all can fail Generality Can be used by diverse applications

Design Point: Authorization /Sub-Pub Management
Many options, e.g., Open group, e.g., publishers push topics and devices subscribe to topics Closed group App Registration(DEV_ID, App_ID) Device Device notifies registration ID to its server;

Design Point: What to Push?
Option 1: Just push signal (data available) to devices and then devices fetch from app servers Option 2: push app data App Device

Apple Push Notification Service
iOS device maintains a persistent TCP connection to an Apple Push Notification Server (APNS) A push notification from a provider to a client application Each push notification carries with it a payload. The payload specifies how users are to be alerted to the data waiting to be downloaded to the client application. The maximum size allowed for a notification payload is 256 bytes; Apple Push Notification Service refuses any notification that exceeds this limit. Remember that delivery of notifications is “best effort” and is not guaranteed. For each notification, providers must compose a JSON dictionary object that strictly adheres to RFC This dictionary must contain another dictionary identified by the key aps. The aps dictionary contains one or more properties that specify the following actions: An alert message to display to the user A number to badge the application icon with A sound to play Multi-providers to multiple devices

APNS Authorization: Device Token
Device token Contains information that enables APNS to locate the device Client app needs to provide the token to its app provider Device token should be requested and passed to providers every time the application launches Each push notification carries with it a payload. The payload specifies how users are to be alerted to the data waiting to be downloaded to the client application. The maximum size allowed for a notification payload is 256 bytes; Apple Push Notification Service refuses any notification that exceeds this limit. Remember that delivery of notifications is “best effort” and is not guaranteed. For each notification, providers must compose a JSON dictionary object that strictly adheres to RFC This dictionary must contain another dictionary identified by the key aps. The aps dictionary contains one or more properties that specify the following actions: An alert message to display to the user A number to badge the application icon with A sound to play

Apple Push Notification Data
Each push notification carries a payload 256 bytes maximum Best effort delivery App provider provides a JSON dictionary object, which contains another dictionary identified by the key aps App specifies the following actions An alert message to display to the user A number to badge the application icon with A sound to play By requesting the device token and passing it to the provider every time your application launches, you help to ensure that the provider has the current token for the device. If a user restores a backup to a device or computer other than the one that the backup was created for (for example, the user migrates data to a new device or computer), he or she must launch the application at least once for it to receive notifications again. If the user restores backup data to a new device or computer, or reinstalls the operating system, the device token changes. Moreover, never cache a device token and give that to your provider; always get the token from the system whenever you need it. If your application has previously registered, calling registerForRemoteNotificationTypes: results in the operating system passing the device token to the delegate immediately without incurring additional overhead.

APNS Example: Client - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // Let the device know we want to receive push notifications [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; return YES; } - (void)application:(UIApplication*)application didReceiveRemoteNotification:(NSDictionary*)userInfo {//userInfo contains the notification notification: userInfo); - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken token is: deviceToken); A major role of a UIApplication object is to handle the initial routing of incoming user events. It also dispatches action messages forwarded to it by control objects (UIControl) to the appropriate target objects. In addition, the UIApplication object maintains a list of all the windows (UIWindow objects) currently open in the application, so through those it can retrieve any of the application’s UIView objects. The application object is typically assigned a delegate, an object that the application informs of significant runtime events—for example, application launch, low-memory warnings, and application termination—giving it an opportunity to respond appropriately. Applications can cooperatively handle a resource such as an or an image file through the openURL: method. For example, an application opening an URL with this method may cause the mail client to launch and display the message. The programmatic interfaces of UIApplication and UIApplicationDelegate also allow you to manage behavior that is specific to the device. You can control application response to changes in interface orientation, temporarily suspend incoming touch events, and turn proximity sensing (of the user’s face) off and on again.

APNS Example: Server $devicetoken ='f05571e4be60a4e11524d76e f430522fb470c46fc6810fffb07af7’; // Put your private key's passphrase here: $passphrase = 'PushChat'; // Put your alert message here: $message = ’CS434: my first push notification!'; $ctx = stream_context_create(); Stream_context_set_option($ctx, 'ssl', 'local_cert', 'ck.pem'); stream_context_set_option($ctx, 'ssl', 'passphrase', $passphrase); // Open a connection to the APNS server $fp = stream_socket_client( 'ssl://gateway.sandbox.push.apple.com:2195', $err, $errstr, 60, STREAM_CLIENT_CONNECT|STREAM_CLIENT_PERSISTENT, $ctx); if (!$fp) exit("Failed to connect: $err $errstr" . PHP_EOL); echo 'Connected to APNS' . PHP_EOL;

APNS Example: Server (cont’)
// Create the payload body $body['aps'] = array( 'alert' => $message, 'sound' => 'default' ); // Encode the payload as JSON $payload = json_encode($body); // Build the binary notification $msg = chr(0) . pack('n', 32) . pack('H*', $deviceToken) . pack('n', strlen($payload)) . $payload; // Send it to the server $result = fwrite($fp, $msg, strlen($msg)); if (!$result) echo 'Message not delivered' . PHP_EOL; else echo 'Message successfully delivered' . PHP_EOL; // Close the connection to the server fclose($fp);

Firebase Cloud Messaging
Very similar to APNS FCM Servers FCM is a newer version of GCM

Inter-thread: execution model with multiple threads Inter-process: component composition Inter-machine: network-wise composition Service discovery Make connections Bluetooth WiFi Direct Cellular Mobile cloud Basic use Thialfi as an implementation example

Example Implementation: Thialfi
Deployed in Chrome Sync, Contacts, Google Plus Goals Scalable: tracks millions of clients and objects Fast: notifies clients in less than a second Reliable: even when entire data centers fail

Thialfi client library
Thialfi Overview Client C2 Client C1 Register X Notify X Thialfi client library Register Update X Register Client Data center Notify X Thialfi Service Application backend Notify X Update X X: C1, C2

Inter-thread: execution model with multiple threads Inter-process: component composition Inter-machine: network-wise composition Service discovery Make connections Bluetooth WiFi Direct Cellular Mobile cloud Basic use Thialfi as an implementation example Overview, abstraction

Thialfi Abstraction Objects have unique IDs and version numbers, monotonically increasing on every update Delivery guarantee Registered clients learn latest version number Reliable signal only: cached object ID X at version Y Why signal only: For most applications, reliable signal is enough

Thialfi Client API

API Without Failure Recovery
Client Library Register(objectId) Unregister(objectId) Notify(objectId, version) Thialfi Service Publish(objectId, version)

Architecture Matcher: Object ID  registered clients, version
Client library Registrations, notifications, acknowledgments Client Data center Client Bigtable Registrar Each server handles a contiguous range of keys Each server maintains an in-memory version Bigtable: log structured, fast write Notifications Object Bigtable Application Backend Matcher Use an internal Google infrastructure publish/subscribe service to disseminate messages to data centers. Matcher: Object ID  registered clients, version Registrar: Client ID  registered objects, notifications

Life of a Notification Client C2 Data center Ack: x, v7 x C1: x, v7
Bigtable Notify: x, v7 Registrar C2: x, v7 C1: x, v5 C2: x, v5 C1: x, v7 C2: x, v7 x, v7 Publish(x, v7) Object Bigtable Matcher x: v5; C1, C2 x: v7; C1, C2 x: v7; C1, C2

Inter-thread: execution model with multiple threads Inter-process: component composition Inter-machine: network-wise composition Service discovery Make connections Bluetooth WiFi Direct Cellular Mobile cloud Basic use Thialfi as an implementation example Overview, abstraction Failure recovery

Partial storage unavailability
Possible Failures Client Library Client Store Server state loss/ schema migration Client restart Data center loss Partial storage unavailability Network failures Client state loss Client Bigtable Registrar Matcher Object Client Bigtable Registrar Matcher Object . . . Data center n Data center 1 Thialfi Service Publish Feed 3/5/12

Failures Client restart Client state loss Network failures
Partial storage unavailability Server state loss / schema migration Publish feed loss Data center outage

How to Handle Failures Principle: Soft state only, where a state at the third party is soft state if the the entity who sets up the state does not refresh it, the state will be pruned at the third party Thialfi has two types of states, and both are soft state registration state notification state State recovery Registration state registratinoReissueRegistrations() at client Registration Sync Protocol to propagate to server Notification state recovery allow NotifyUnknown()

Recovering Client Registrations
Registrar Matcher Object Bigtable ReissueRegistrations() x x y y Register(x); Register(y)

Syncing Client Registrations
Register: x, y Registrar Matcher Object Bigtable Hash(x, y) x y x Hash(x, y) Reg sync y Merkle tree for syncing large number of objects Goal: Keep client-registrar registration state in sync Every message contains hash of registered objects Registrar initiates protocol when detects out-of-sync Allows simpler reasoning of registration state

Recovering From Lost Versions
Versions may be lost, e.g. schema migration Inform client with NotifyUnknown(objectId) Client must refresh, regardless of its current state

Notification Latency Breakdown
Batching accounts for significant fraction of latency

Thialfi Usage by Applications
Language Network Channel Client Lines of Code (Semi-colons) Chrome Sync C++ XMPP 535 Contacts JavaScript Hanging GET 40 Google+ 80 Android Application Java C2DM + Standard GET 300 Google BlackBerry RPC 340

Pointers to Additional Work
See Facebook Wormhole pub/sub design See Sapphire automatic mobile/cloud split design

Inter-thread: execution model with multiple threads Inter-process: component composition Inter-machine: network-wise composition Service discovery Make connections Bluetooth WiFi Direct Cellular Mobile cloud Near Field Communication (NFC)

RFID (Radio Frequency Identification)
The initial development of NFC is RFID, with many applications, e.g., Secure Entry cards Supply chain management

RFID Basic Architecture

RFID Tag Tag is a device used to transmit information such as a serial number to the reader in a contact less manner Classified as Passive – energy from reader Active - battery battery Semi-passive – battery and energy from battery and energy from reader

RFID Reader Also known an interrogator
Reader powers passive tags with RF energy (for passive tags) Consists of: Transceiver Antenna Microprocessor Network interface

Nexus Hardware Front-facing camera Earpiece Power button
Volume buttons Headset jack Speaker USB Type-C port Laser auto focus & dual-LED flash Rear-facing camera NFC SIM card tray Fingerprint sensor

RFID Passive Receiver: Foundation

Near Field RFID <= 100 Mhz

How far can a passive tag be read?
Assume distance limited by power available to run the tag’s circuits

Maximum Distances to Read UHF Passive Tag

Example NF Use: Contactless Smart Card
Proximity Smart Cards (13.56 MHz) Range = 4 inches (10 centimeter) Baud rate = 106 kilobaud ISO/IEC 14443 Vicinity Smart Cards (13.56 MHz) Range = 3 feet (1 meter) Baud rate = kilobaud ISO/IEC 15693 Animal Identification (134 KHz, 125 ISO 11784/11785 VeriChip as human plantable RFID tag (134 KHz)

Far Field RFID

RFID MAC Protocol Access phase Select phase
Single out particular tag population with one or more bits with query tree protocol protocol Inventory phase– identify individual tag using Q protocol (slotted-aloha based) Reader sends Query with parameter Q and Session number (Q=4 is suggested default) Reader creates slotted time Tags pick random 16-bit number as handle Tags in requested session pick a random number in the range [0,2^Q-1] for slot_number If slot_number = 0, backscatter handle If slot_number != 0, wait that number of slots to backscatter Reader ACKs individual tag with handle and goes to access phase. All other tags wait. If more that one tag answers, reader can send same Q again or send modified Q Access phase Reader interacts with tags requesting EPC number and any other information

Select Phase: Query Tree

Inventory Phase (Q Protocol; Slotted Aloha)

Android NFC User Programming API
System discovers NFC tag Key issue: how to determine the application to be invoked Implication: need a tag dispatch system Android tag dispatch design Parsing the NFC tag and figuring out the MIME type or a URI that identifies the data payload in the tag. Encapsulating the MIME type or URI and the payload into an intent. Starts an activity based on the intent.

Tag to MIME/URI Requires tag uses NDEF (NFC Data Exchange Format), which consists of a sequence of NDEF records First record provides 3-bit TNF (type name format)

Intent Dispatch ACTION_NDEF_DISCOVERED: This intent is used to start an Activity when a tag that contains an NDEF payload is scanned and is of a recognized type. This is the highest priority intent, and the tag dispatch system tries to start an Activity with this intent before any other intent, whenever possible. ACTION_TECH_DISCOVERED: If no activities register to handle the ACTION_NDEF_DISCOVERED intent, the tag dispatch system tries to start an application with this intent. This intent is also directly started (without starting ACTION_NDEF_DISCOVERED first) if the tag that is scanned contains NDEF data that cannot be mapped to a MIME type or URI, or if the tag does not contain NDEF data but is of a known tag technology. ACTION_TAG_DISCOVERED: This intent is started if no activities handle the ACTION_NDEF_DISCOVERED or ACTION_TECH_DISCOVERED intents.

Backup Slides

CS434/534: Topics in Networked (Networking) Systems Mobile Networking System: Making Connections: Cloud; NFC Yang (Richard) Yang Computer Science Department.

Similar presentations

Presentation on theme: "CS434/534: Topics in Networked (Networking) Systems Mobile Networking System: Making Connections: Cloud; NFC Yang (Richard) Yang Computer Science Department."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CS434/534: Topics in Networked (Networking) Systems Mobile Networking System: Making Connections: Cloud; NFC Yang (Richard) Yang Computer Science Department.

Similar presentations

Presentation on theme: "CS434/534: Topics in Networked (Networking) Systems Mobile Networking System: Making Connections: Cloud; NFC Yang (Richard) Yang Computer Science Department."— Presentation transcript:

Similar presentations

About project

Feedback