Matt Stabeler

Today I met with Simon and his subgroup, to which I have become an adopted member, to get some feedback about my PhD direction.

I had previously met them and gave a 25 word overview of my PhD topic. At that time they were very helpful in giving feedback about the viability of my topic, and we suggested that at the next meeting we would talk in more detail about myself and Olga’s research.

At this meeting, I gave an overview that I was interesting in researching what the combination of social networks, and personal devices, to create a Delay Tolerant Network technique that uses the properties, facets and behaviours of human networks and mobility to send messages. With a view to using this network for metropolitan area environmental sensing.

I described my thoughts that we are reliant upon a infrastructure for our networking needs today, but there are various costs to this. To the user, to the providor, and perhaps to the environment. I gave some rough calculations as to the cost of deploying 1000 motes for a year which based their reporting communications on 3G networking, and whilst an individaul mote only used approx 240kb per day of bandwidth, this equated to 85GB per year, at a roughly estimated cost of 42,000 euros per year.

I said that I felt it is feasible to deploy some other mechanism for comunications that utilises the power in our pockets. I asked for confirmation that this was a valid topic, and that there was enough scope for research in this to make it a valid topic.

The general feeling was that there were some novelties in this, and Davide (Cellai) gave a very good explanation of similar problems in nature (Protein Interaction Networks) and felt that the science was in finding a way to describe such dynamic networks, and that there was allready a lot of research in static networks, but not in these dynamic ones.

Point 1: There is no formal language to describe dynamic networks/ the dynamics of networks

Question 1: How do you descibe how a network is evolving?

Question 2: What parameters do you need/have to describe?

Cosideration 1:  Failure models

Simon pointed out that this type of research is validated by NASA who are looking for ways to use DTN in swarm based autonomous missions to mars/space. Whilst this is not directly related (due to a lack of social networks), the ideas can still be used.

Davide also pointed out that in his and Graeme’s research, they have identified that mobility models provide a structure to, and therefore affect, dynamic networks, and that there is an area of research in this space. (which confirms my previous thoughts and efforts towards generating a reliable mobility model)

Met with Lorcan to talk about how i’m getting on with my PhD. I explained that I was a little unsure about the direction of my PhD.

I also told him about the papers I am writing – the first, a paper about Basadaeir for Pervasive LBR, deadline 27th Jan. I explained that the user study will be for developers to test out the API and comment on it, and the concept of the system.

The second paper, with ross is to do with pervasive advertising, and using Basadaeir as the context server for advertisments. Deadline 10th Feb.

Lorcan suggested that whilst it is a good idea to get something published about Basadaeir, I should not put too much effort into it, unless it will help my PhD out.

He suggested that I take a look at a few survery papers in my area, pick out the challenges, and write them down, then, from this list pick one or two, and write briefly how they might be solved, and come back to him.

Met with Paddy and discussed what we need to be on with – we both seem to have been thinking about different things – I seem to have gone down a route of something to do with mobile phones – but it needs to be linked to what we are getting at. I said that I don’t really know what wearable computing really means – as I haven’t seen it in the flesh!

Really need to get into the idea of what infrastructure is needed to make wearable systems work – think of it more as network of wearable sensors.

What issues are there when we are thinking about transferring data amongst nodes – what if instead of being centrally managed – what if they could freely communicate with each other.

Discussed the idea of city wide environmental sensing – a mixture of fixed and mobile nodes which are tagging and recording data – offloading to nodes with big pipes – how does this work – and how do we implement it?

Also need to think about issues such as transient and persistant data – what is kept and what is shared and removed – what is private what is encrypted what is not?

Example application is
citywide environmental monitoring – fixed nodes talk each other and share data,
they also talk to mobile nodes to get data –application to monitor an area.

Nodes about the body can
communicate to other nodes on other bodies, handing off data – gossiping –
every piece of data has timestamp – and is tagged so that that it can be
synchronised at a later date.

Also –  talked about  developing some things that we say is good for
wearable computing – i.e. p2p vs managed nodes then compare previous wearable implementations
to our idea of whats best and see if they succeeded.

Hundreds of shimmers
downstairs in clarity to have a play with.

Speak to Julie doyle
about user study – work out what we are trying to get out and keep it in the back of my head.

Paddy suggested this was a turning point – are we
interested in hard computer science part?  Or more the HCI part?

Overall we really get down to the
basics –

What will be good
about P2P vs Central Node?

What is persistant
what is transient?

Matt Walsh – they have
the OS with low level access to data – what do we need to do to get something up and running?

Part 1 – Wearables

Assumptions – Paddys Notes

Met with Paddy to talk about Wearable computing Assumptions.

Discussed the short-list that I had come up with: Assumptions about Wearable Computing

Paddy gave his thoughts about what I had come up with – and we came to the following main assumptions that we will look at and question their validity:

• Communication bandwidth is an issue
  • What data do we really send? – Sensors/Video/Other
  • 3G is quick
• Wearables are individual
  • Data is private, Infrastructure is community
• We need to optimize for power
  • What if we don’t – usage patterns
• Processing power is minimal
  • Not any more – processing power is good – PDA -iPhone etc.
• One managing node
  • Emergence
  • pure p2p
  • individually addressable(ipv6?)

Tasks:

Matt:

Rethink the systems/paradigms/stuff that I have read/seen/tested and see what would happen if we took out these assumptions.

Suggest that these things are not really true anymore, and that they can be considered to be a myth.

Write up an internal paper/report (3 pages) that suggests this, and  covers the reasons why, and see what people think. – Debunking the Wearable Myth

Part 2 – Basadaeir

I suggested to Paddy that  we should do something with Basadaeir, and that it is one of the missing parts of the construct project, the profiled/static/persistent entity that contributes to the pervasive environment. He agreed that we should develop it, and was planning to require that all new people register with it.

He also suggested a case/research study for it, building collaboration not just through keywords, but also by matching presence of other people at the same time – e.g. when people are often in the same place at the same time, they may be connected somehow.

Tasks:

Matt:

Get the system robust and working – so that people can sign up and start using it –

• CRUD for profiles
• Efficient processing of data
• API for external applications
• Internalised third part applications (like fbook) – so that others can solicit more information about topics – e.g. research keywords.

Paddy:

Will tell people that this system will be available, and will expect that at some point Matt will have it working – no particular timescale.

I get very easily distracted with ongoing projects that perhaps I should not be thinking about. To identify and remove any distractions, I listed them out as follows:

• Basadaeir (Website Tweaks)
• Bluetooth Spotter
• Oldtowncacarnivalweek.co.uk(Tweaks, Photos)
• Twitter
• Facebook
• Stabeler.com (Tweaking, Blogging)
• Music
• Olympic Games
• Beer Drinking
• Coffee Breaks
• IM
• Cleaning Desk
• Getting Drinks
• MAC Mini setup
• Online Banking
• Watching Movies/TV
• Worrying about direction of research
• RSS Feeds
• Email!!!!!
• Googe Analytics
• Google Adsense

Most of which are distracting whilst at uni (when I should be concentrating) – so – now I have identified the things that distract me, I should be able to avoid them more easily.

Met with paddy this morning to talk about where to go from here.

I’ve been reading around Context, Privacy, Infrastructure, Management etc. in relation to wearable computing. There are a number of texts that mention it, but nothing (so far) that has dealt with it directly.

Paddy suggested reading and using the idea from http://infoblog.stanford.edu/ that you take the main assumptions about an area, list them out, then change one or two of them, and see what happens. (yet to read artical)

Also, paddy suggested to have a think about stream processing.

I should also look at the locations/conferences/groups that are doing these thing – i.e. find papers that are newer, and may not be highly cited.

Suggested conferences to look into:

MobHoc, MobiCom, Middleware, etc

Paddy also mentioned that reading can expand to fill all available time, so don’t let!

I recently attended the Pervasive 2008 conference in Sydney, Australia. where I submitted my paper – SensorMash: Exploring System Fidelity Through Sensor Mashup, which I co-authored with Steve Neely and Paddy Nixon.

I presented a poster and a one-minute-madness talk, for which I won best one-minute-madness.

I have/will write(n) a summary of the events there (as a reflection on my experience), and the ideas that I had for new projects as a result of the conference.

The last couple of days I’ve been trying to get Ubitracker to run directly from construct. I have created a Contruct class in PHP which deals with the construct communications, for both querying (SPARQL) and inserting data (RDF Triplets).

This enabled me to create an application that uses this to get the data from (any local) construct directly, and format it as XML as expected by the ubitracker interface.

There is more work to be done to do with meta-data needed to run the interface (such as tag/object bindings), once this has been completed, the interface can be run and installed very easily. This would allow other groups who utilize Ubisense, to run this application. A blue sky view of this project would be to create a platform within which sensor ‘plugins’ could be developed and used to display interesting things to users.

Further stages of development will require some rethinking of the output XML structure, to include other sensor types and data (such as Bluetooth readings/locations, Calendar linkage, Webcam images, etc. etc.)

It will be particularly interesting to develop an application which uses all of the location type data to get a good approximation of an objects (persons) location.

I’ve been busy with module stuff, and have been generally experimenting with construct and ubisense and the Ubitracker site the Tom and I created.

I created the backend system (Java/MySQL/PHP) and the management interface for the system (PHP/MySQL):
http://kind.ucd.ie/~matthewstabeler/ubitracker/

Which allows you to manage data about users, and also to send notifications to objects(tags) in the ubisense system, which is quite good fun!

We plan to link this interface with Construct and eventually run the live system directly using data from Construct.

Tom created the front end interface:
http://kind.ucd.ie/~tomholland/ubitracker/

Which tracks the users in realtime (ish), we plan to make some sort of playback mechanism for data within the ubitracker system.

Also, I finished the Natural Comuting assignment, which was eventually entitled, Optimum Coverage of the Autonomous Sensor Swarm: Sensor PSO. This system was a simple implementation of Particle Swarm Optimisation to optimise the positioning of sensors. Details are on my projects page here

I’m now working on the idea of Categorizing sensors, and developing a mobile version of construct, I posted more details on this blog here.

I also had an idea about location sensing using derived information available to social networking sites, this started as more of a personal thing, but seems it might have some academic merit! But i’ll update about that when I’ve got something tangible to show!
!