Instructed by: Alex Kogan Performed by: Adam Levi Tal Steier

Construct a Bluetooth manager for mobile phone which will activate and de-activate the Bluetooth device according to User’s pre-defined rules Learning mechanism

GUIManager File System + Named Events

GUI process send notification to manager thread according to the user’s requests: Close Manager. Reset Learning. Update (Reload) Rules List. Manager process awakes and immediately handles request.

* Since Named Events are not supported directly by the compact framework, we used P/Invoke to access them. Manager Named-Event: PowerAwareBT_EVENT Wait For The Event Thread UI Rules-list on the Storage card

Allows turning off GUI while the manager is running. Saves system resources. Since manager is always running and GUI is sparsely used. Improved user experience Handling complex requests does not affect GUI response time. Separation of different program components better design.

Define rules Activate / Shutdown manager There can be only one Reset learning Reset the user learnt behavior Default behavior - always on

When the user opens the UI, the rules-list is shown We used big buttons because of the touch-screen interface Adds a new rule Modifies the selected rule Deletes the selected Rule

Clicking will open the Add new Rule dialog A familiar windows-style dialog that defines the rule’s properties Correctness checks are made to ensure the rule is well-defined: Rule applies to at least one day Times are well defined Rules does not collide

Manager User Bluetooth Operations Predefined Rules Battery Power Learning Mechanism Cellular Cell User ‘s Requests

While true: Check for changes from previous iteration Rules updates User commands Determine Bluetooth required state According to user definitions According to AI If needed - Sample for other Bluetooth devices Look for paired devices that are In Range. Sleep

Time Line Sunday 6:00 – 6:10 Sunday 6:10 – 6:20 Sunday 6:20 – 6:30 Cellular Cell History Cell: 3e-3321 Cell: F2- 3h94 Battery Power High Low

User behavior is not constant in time Algorithmic solution Battery power is not a part of user behavior Treat battery as “go / no go” Cellular cell does not reflect geographic position Cellular cell data will only affect sampling frequency

On descending priorities: User bluetooth operation Don’t touch for 30 minutes after user changed bluetooth state Rules If rules are defined – act accordingly Battery power If battery low – switch bluetooth off User learnt behavior

A week is divided into 10 minutes slots For each slot we hold a state machine Each sample changes the state accordingly. Decision is made according to the state of all slots in the current time slot area Prefer “On” Positive example – bluetooth in the system paired list is discovered Off Hard OffOnOn Hard

Simple Even more important on cell phones Provides decision from day 1 Even before any user data is received Avoids turning the bluetooth on and off frequently Via a smoothing mechanism Prefer “On” Assumption on user preference.

1 slice = many samplings Default is 2 Number of samples per slice depends on cellular cell history Good cells – up to 5 samplings Bad cells – no less then 1 Samples average determines positive / negative result for the slice

Data is saved to the storage card to support recovering after cell phone shutdown Learnt behavior and cellular cell data Rules Manager process is automatically started upon cell phone activation GUI is accessed through “start menu”

Decision making can consider more parameters For example: GPS Empiric research: Application battery power savings Program characteristics: Size of state machine. Optimal number of samplings. Weighted average of decision factors More flexible rules Hint the system instead of telling it what to do Extended user control But no one uses the “properties forms”…