Thursday, December 29, 2005

Dimensions of Service Discovery

Need of Common Platform: With heterogeneous protocols supported by various entities involved in the virtual network, there would be diversity in service discovery protocols; hence a common platform or protocol establishment is a must requirement for enabling interoperability among service discovery protocols.

Dimensions:

  • Service and Attribute Naming: Namespace based to avoid collisions and sustain uniqueness, human friendly service names, no usage of predefined templates for service names and attributes to support a common platform vision.

  • Initial Communication Method: Unicast communication can only be used service discovery clients have specific prior configuration, hence such communication is infeasible in MANETs. A few Multicast messages to the directory, client can than proceed by explicit unicast messages. Link layer Broadcast can also work for a hop of distance.

  • Discovery and Registration: Announcement based seems to be less suitable as client needs to listen and maintain a list of available services. Query based suits good to MANET and a client need not to process uninterested announcements.

  • Service Discovery Infrastructure: Directory based models have a dedicated directory that maintains, processes, announces service information. This model is good when hundreds and thousands of services are incarnated in the network. Non-Directory based models have no dedicated components. When a query arrives, each service processes it; and replies if it matches with the desired one. A client can record service information for future usage.

  • Service Information State: Soft State has an explicit service demise announcement; services too have explicit lease declaration in them, a graceful removal from the directory and announcement from the service itself. Hard State requires few service announcements and housekeeping. However, clients require to poll services to make sure that they are alive.

  • Discovery Scopes: Proper discovery scopes minimize unnecessary computation on clients, services, and directories. Network topology based, User Role based, and Temporal Context based can be categorization of scopes.

  • Service Selection: Although discovery scope can limit the number of service matches, there can a list of services available, and a selection could be required from them, Selection can be from user as manual, prompting user to choose or can be automatic, where the discovery protocol selects the service. This approach simplifies client programs and requires little user involvement. Good aspects that can be handled in automatic service selection are network hop distance to the service from requester client, load factor on services, service side robustness etc.

Wednesday, December 28, 2005

Pervasive Computing

I found a very good definition of pervasive computing:

It is characterized as a combination of distributed systems and mobile computing but also augmented by smart spaces, invisibility, localized scalability and uneven conditioning. A more detailed research space includes user intent, adaptation strategy, high-level energy management, client thickness, context awareness, balancing proactivity and transparency, privacy and trust.


When Edison finally found a filament that would burn, did he see the possibility of silent but pervasive electrical current flowing throughout our homes, cars and communities?

Tuesday, December 27, 2005

Known Issues

  • Mobile phones do not yet support an IP stack over Bluetooth. Devices which only support Infrared or ZigBee would be disconnected from the virtual network created by framework.

Monday, December 05, 2005

Live on Wireless

Amazing new world utilities coming up now a days, below are a few to seek out,

  • Handheld equipment hoping on reconfigurable frequencies defined by middleware stacks (Extremely useful in military applications)

  • Context aware applications ranging from vehicular computing to Sensor based Ad Hoc computational systems, that is your car system can automatically adapt its configurations (may be speed in automatic drive, transmission ratios of gear box, audio tracks of your sound system) according to the profile of the user driving the car

  • Server side components for handheld devices

  • Virtual Home Imaginations (HP is going great work in it)

  • Frameworks to support heterogeneous MAC layer environment, so that your handheld can now navigate seamlessly on Bluetooth, CDMA, GSM, 802.11 (a-g), even to 3G networks

  • Dynamic service composition and delegation, such that your handheld can request a service and according to the request attributes, hosted services can jointly combine and process the request.

  • and Disconnection operation to name a few (a scenario can be like, your doctor can asynchronously prescribe you diet of specific calories even when you are not in doctor's clinic and you can view that on your mobile or laptop while taking a morning walk in some lush green vally...
  • Wednesday, November 30, 2005

    Asynchronous Communication

    There is a essential need for component(s) to support asynchonous behavior. Main points are:
  • Exchange of Request data and Response data between server and client. Particularly at the time of demise or disconnection of the receiving entity (in case of response from MH), assuming that sending operation is successful. Also in request scenarios where FH has pushed the request, but the request is travelling along the network but not reached to the server.

  • Exchange of control information between Routing layer. Exchange of Mobility layer connection information, handoff information.

  • Message broker can hence act as delegate, as indirectly it would be supporting disconnected operation.


  • TODOs:
  • Component identification and deployment diagram

  • Issues of hosting JMS and CNS on low footprint devices.

  • Many more...
  • Tuesday, November 08, 2005

    What lies Next

    I listed following points on 08 April, 2005,
  • Impromptu Service Discovery - UPnP, JINI, SLP protocols

  • Minimal CORBA - low footprint

  • Asynchronous Behaviour - asynchronous messaging of request-responses, cache, use of CNS

  • Network Adaptation - access to MAC layer, adaptation according to MAC layer

  • Disconnection Operation - object by value, externalization and life cycle services, Use of mac layer for switching modes

  • Optimizing IIOP layer communication - analysis of architecture

  • Integration with Non- CORBA clients- SOAP, web service clients and others

  • Security Aspects- Authentication and Authorization services, security services

  • Early thoughts on Mobile ad-hoc networks - using Peer-to-Peer Computing


  • In last 8 months I delved inside very few of above, but I am recharged now, I would move to following points (In priority):

  • Asynchronous Behaviour - asynchronous messaging of request-responses, cache, use of CNS

  • Minimal CORBA - low footprint

  • Disconnection Operation - object by value, externalization and life cycle services, Use of mac layer for switching modes

  • Network Adaptation - access to MAC layer, adaptation according to MAC layer

  • Integration with Non- CORBA clients- SOAP, web service clients and others

  • Optimizing IIOP layer communication - analysis of architecture

  • Security Aspects- Authentication and Authorization services, security services
  • Wednesday, October 19, 2005

    Epidemicity

  • Ad hoc networking modeling with Omnet++

  • Implementation of client side request interceptor

  • Relook at Layers

  • Message Middlewares for Asynchrony
  • Thursday, September 08, 2005

    Ad hoc On-Demand Distributed Minimal Hop based Cycle eliminated Routing Algorithm

    1 u = v

    1.1 Nbu[v] = local

    2 if u!=v then, Nbu[v] w, where w is the first neighbour of u on a shortest path from u to v
    (Multithreaded operation at u)

    2.1 Sends Rreq to Neigh[u]

    (operation at w)
    2.1.1 For each Neigh(u) having d(v) in cache

    2.1.1.1 Reply to Rreq to u by exponential time proportional to hops to v.

    (Route Maintainance Operation)
    2.1.1.2 Make a Async message (mydist, v, d) to all its neighbours

    (operations at Neigh(w) say z)
    2.1.1.2.1 Receive message (mydist,v,d)
    2.1.1.2.2 Decide on d(z,v)<= d(w,z)(1)+d(w,v)
    2.1.1.2.3 Reply to w if false (notifying that path from w is minimal)
    2.1.1.2.4 Update Cache, Nbu[v] vector = w
    2.1.1.2.5 Notify Neigh(z) about change

    2.1.1.3 Make a reverse route entry by Lsd

    2.1.2 If d(v) = ndef (Recursive Route Discovery operation)
    2.1.2.1 Sends Rreq to Neigh(w)
    2.1.2.2 Append route list Lsd with w

    2.2 Receive and process Rres

    2.2.1 For Rreq TTL accept Rres
    2.2.2 Process minimal hop and 2.2.3 Extract Lsd and make route entry for Destination and Intemediate nodes too.

    3 If no route to v

    3.1 Neigh(v) = udef
    3.2 Propagate Rerr to intermediate nodes so that stale entries (containing route for v from u) in other Uks can be removed.


    Satifiability conditions for Nbu[v]
    a if u=v, then, Nbu[v] = local
    b1 if u!=v then, Nbu[v] w, where w is the first neighbour of u on a shortest path from u to v
    b2 if u!=v then, and for all w Dw[v] >= N-1, then Du[v] = N {u and v are in different connected components}
    c if no path from u to v exists then Nbu[v] = udef

    Monday, August 22, 2005

    Routing table characteristics in Mobile Adhoc NETs

    Robustness - In case of topological changes.
    Adaptiveness - In case of heavy load at particular links (paths) hence some alternative paths need to be selected.

    Routing Characteristics can be categorized as:
  • Minimal hops
  • ,
  • Shortest path
  • , and,
  • Minimal delay


  • Good observation: A minimal (optimal) path need not to be unique. That is, there may exist other paths of the same cost. Then, load factor on the shortlisted candidates can be a good decisive factor.

    Friday, August 05, 2005

    802.11 Notes continues...

    Bit Error Rates in Wireless medium are the main drawback of them, comparatively BERs in Wireless medium are 10 times more than Wired LAN cables. The main reason for BERs are Atmospheric Noise, Physical Obstructions along the path, Multipath Propagation and interference.
    Most of the WLANS operate on Spread Spectrum Modulation. which operates over a wide amount of bandwidth. Interference is also caused by multipath fading of the WLAN signals, which results in random phase and amplitude fluctuations in the received signal.

    Inward interference comes from devices transmitting in the frequency spectrum used by the WLAN. A number of techniques the operate either on the physical or MAC layer like, Alternative modulation techniques, antenna diversity and feedback equalization in the physical layer, Automatic Repeat Requests (ARQ), Forward Error Control (FEC) in the MAC layer are used to mitigate this inteference.

    Outward interference occurs when the WLAN signals disrupts the operation of adjacent WLANs or radio devices.

    Further problems are Hidden and Exposed terminal cases.

    Physical layers:

    IR: operates near to visible rays wavelength 850nm, produced by semiconductor laser diodes or LEDs, since their electrical to optical conversion behaviour is linear.
    Can be produced using one of three ways: Diffused transmission in omni direction, reflection by ceiling or focused transmission. IRs are demodulated at the receivers using their amplitude, not their frequency or phase, reduces the receivers complexity. IR rediatons are immune to electromagnetic noise. IR systems share a part of spectrum that is also used by the Sun, hence can work practically in indoor application, same the case with Florescent lights. The IEEE 802.11 physical layer specfication uses Pulse Position Modulation (PPM) to transmit data using IR radiation. PPM varies the position of a pulse in order to transmit different binary symbols. IR transmission works at 1 or 2 Mbps.

    RF: RF is robust to florescent lights and outdoor operations, can penetrate non-metalic objects. RF equipment is subject to increased cochannel interferece, atmospheric and man-made noise, high-current circuits.
    RF Bands: 902 MHz, 2.4 Ghz and 5.8 Ghz
    Adv Factor: The higher the RF band, lesser would be the interfernce.
    Disadv Factor: The higer the band, lesser would be the transmission range.
    Spread Spectrum: RF uses spread spectrum technology. The idea is to spread the transmitted information over a wider bandwidth in order to make interception and jamming more difficult. In a spread spectrum system, the input data is fed into a channel encoder, which uses a carrier to produce a narrowband analog signal centered around a certain frequency. This signal is then spread in frequency by a modulator, which uses a sequence of pseudorandom numbers. At the receiving end, the same sequence is used to demodulate the spread signal and recover the original narrowband analog signal. The recoverd original narrowband analog signal is fed into a channel decoder to recover the initial digital data. The hopping sequence is defined by the 'seed' of the random number generator.
    Spread spectrum has been proven very effective in combating fading. Since a spread spectrum is very wide in frequency, fading only affects a small part of it.

    FHSS: Hops over frequency to frequency. Time spend on one frequency is called a chip. The receiver executes the same hopping sequence while remaining in synchronization with the transmitter and thus receives the transmitted data.

    DSSS: Each bit in the original spectrum is represented by a number of bits in the spread signal. This can be done by binary multiplication (XOR) of the data bits with a higher rate pseudorandom bit sequence., known as the chipping code. The resulting stream has a rate equal to that of the chipping code and is fed into a modulator, which converts it to analog form in order to be transmitted.

    Bit Rates: IEEE 802.11 covers FHSS, DSSS and Infrared Technologies. IEEE 802.11b works at 5.5-11 Mbps and uses DSSS for spreading the spectrum. IEEE 802.11a (HiperLAN2) operates at 5Ghz, and acheives data rates around 54 Mbps. It uses OFDM as opposed to spread spectrum used in Bluetooth, 802.11 and 802.11b. Bluetooth hops around 1600 hops per second which is extremely high as compared to IEEE 802.11 (2.5 hops per second). Thus, due to overhead of switching between the frequencies could cause some delays, and affect the throughtput in that way, that's why actual output data rate of bluetooth is around 30 to 400 kbps, whereas that of 802.11 is 1-2 Mbps. Obviously, 802.11b has a higher data rate than 802.11, 5.5-11 Mbps.

    Interoperability of protocols

    Overlapped and heterogeneous protocol support for servant clients. Support of Discovery at different protocols is a great feature. Moreover, Services from servants can interoperate with services at different protocols. Enterprise Service Bus can support the features and interoperbility of services.

    Friday, July 08, 2005

    About Service Discovery Architecture

    Service Location Protocol: Directory Agents are the renaming of MGs or various central authorities. Service and User Agents resides on the mobile devices and work the same as a subset of the CORBA framework components.

    JINI: Has a Jini Lookup Service (JLS), exactly as MG.

    Universal Plug and Play: UPnP uses SSDP over HTTP in two fashions, UDP(HTTPU) and UDP(HTTPMU). A service joining can unicase or multicase to the default selected set of clients or peers about it's arrival in the network and start of service. A client can directly contact a server based on URL or can multicase a request. UPnP seems to be a resonably good one since its architecture says 'NO' to centralized directory server.

    SALUTATION: The salutation architecture defines another centralized entity as Salutation Manager (SLM), exctly as SLP's Directory Agent, or JINI's JLS or Nomadic's MG.

    CONCLUSIVE POINTS
    About UpnP
    Hence, I am going to write or delve deeper into Universal Plug and Play only in the further blog contents. UPnP has five steps in all:
  • Discovery:
  • Based on SSDP over HTTP. When a device comes it multicast to the control point about it's service description. When a control point comes, it searches for devices of interest on the network.
  • Description:
  • After discovering the device, the control center retrieves the device (I assume service too) description from the URL provided by the device.
  • Control:
  • Control point sends control message to the control URL for the service.
  • Eventing:
  • In case service changes any of the service variables or other information about itself, it informs the control center with a event message about the change.
  • Presentation:
  • Some devices provides a URL like MBeans to allow a user to view device status or control the device.
    About SLP
  • Advantage factor of SLP is that it supports service browsing and string based query.

  • About Nomadic
  • Cooperation among MG's in nomadic environment is also a good thing to do.



  • Few Points
    Advantage of Nomadic over MANET are:
  • Scalability

  • Response Time

  • Load Balancing
  • Tuesday, July 05, 2005

    Dimensions of Discovery

    I can classify various discoveries in MANET and Pervasive computing as:
    a.) Route Discovery
    b.) Device Discovery
    c.) Service Discovery

    I can also classify demises in:
    a.) Device Demise
    b.) Service Demise
    c.) Route Demise

    I can classify the maintainance as:
    a.) Route Maintainance

    As far as Demise and Discovery dimensions are concerned:
    Device property is a superset of the Service property. That means that happening of the Device entity would result in the same happening of the Service entity.

    Tuesday, June 28, 2005

    Nightly

    DNS - IP address - Produces IOR
    Since there is no MG, hence at time of birth there is no need to produce IOR.
    MH produces original IOR and ukey or Hash and distributes to all neighbour MHs to make an entry in their tables.
    On movement Birth MH might not be connected to the old set of MH and might be connected to the new set of MH.
    Birth MH notifies new set of MH not the old set of MH.
    How old set of MH would be notified about the IOR getting dirty?
    On movement of MH, devices which are immediate neighbour would get notified about device demise.
    Request can be received from MH or FC.
    In CORBA, a request can only be launched if a client has IOR.
    1. An IOR can be distributed to the connected consumes(FC or MH).
    2. A request of search can be issued by consumer (FH or MH) to connected MH by giving some search attributes, so that the receiving MH can do:
    2a. Forwards the request attributes to it's connected MH if can't be answered.
    2b. Replies back to the client with the modified or swapped IOR.

    In approach 1, as IOR gets dirty it becomes difficult to trace. There would a heavy overhead of the distribution of the new IOR, I think this would need to be distributed to almost all.
    In appraoch 2, a search request would be forwarded and it need to return the latest IOR or IOR information.
    In appraoch 2, a category of identifying parameter needs to be passed by the servant to the birth MH and then by birth MH to connected MH, so that searching of the servant based on attributes can be done.

    On movement the search attribute related entry in registers of neighbour MH is modified, so that the latest entry remains.

    Monday, June 27, 2005

    AODV (Ad Hoc On Demand Distance Vector)

    Introduction
    combination of DSR and DSDV.
    Route discovery and maintainatance from DSR.
    Hop-by-hop, sequence number and periodic updates from DSDV.
    Rreq packets contains last known sequence number for destination.
    When a node recives a Rreq for a destination it has a route to, it generates a Rrep with the updated sequence number and number of hops.
    Each node that forwards the reply back to the originator creates a forward path to the destination.

    Wednesday, June 22, 2005

    DSR (Dynamic Source Routing)

    Introduction
    1. Source routing (full routing information)
    2. On demand routing updates
    3. Route Discovery and Maintainance
    4. Bidirectional routing information updates by reversing the route request path.
    5. Source initiates the Rreq (having Vs,Vd,Lsd).
    6. Destination receives Rreq (may be more than one over the period of time), then sends a Rrep (a reverse mesaage) from the path which has shortest Lsd listing.
    7. Intermediate nodes (Vi-Vj) also communicates bidirectionally to update their information. If fails then, Vi informs the Vj about Rerr and Vs initiates a new Rreq with a different route.

    About DSDV (Destination Sequences Distance Vector)

    Introduction:
    Each node maintains a set of distance or cost vectors for each possible destination.
    Each node periodically broadcasts its routing table to all neighbours.
    The routing is hop by hop.
    Predicated table structure tuple can be like this:

    {Destination Mobile Node Identifier,Sequence Number, Next Neighbour hop information in direction of deestination}

    Routes have sequence number.
    Routes with higher sequence number are more favorable.

    Questions:
    1. Periodic updates should be send and received from whom ?
    Each node periodically broadcasts its routing table to all neighbours.

    2. Route decisiveness based on what matric ? weight or latest or other factor ?Latest is a must as the use of sequence number shows.

    Advantage Factors:
    1. Guarantees loop-free routes.
    2. Simple logic. (Should not be considered as adv. point)

    Disadvantage Factors:
    1. Hop by hop routing instead of Source routing.
    2. Periodical updates.
    3. Heavy overhead of exchange of routing information between neighbours.

    Monday, May 30, 2005

    Merger Notes Revised

    Efficiently route or request data among entites.
    Topology of network is dynamic due to intermittent connections.
    There always requires an flooding sort of algos for going to p2p side, but raises the scalability problems. Need to take things from application layer to network layer as the P2P and MANET ranges the same. Good sign is CORBA framework proposed in my previous paper also ranges the same hence all issues can be taken into consideration and solutions can be mergerd with the disconnection, swizzling, mobility (I and II) layers. Mobility layer is going to work extensively in the revised version.

    Peers should communicate to each other periodically.
    These protocols should be triggered more frequently for MANET.
    I can convert MHR into a neighbour tablefor nearest keys for DHT, that would imporve robustness and they need to be updates periodically.

    Discovery mechanism

    Rship Approach: Forward discovery queries using similarity, history and random Rships.
    Updating Rships can be the activity performed while migration of servants.
    Acquiring Rships can be performed as conduction process.
    Discovery result backtracking would make system to learn much quicker.
    Tradeoffs are overheads in all above operations.

    Does above works better than Distributed Hash Table? Consider two cases for comparision: a) when the queries are similar and b) when queries are random.

    Flooding: Obviously, it is going to take too much bandwidth, so it arises scalability issues.

    Distributed Hash Table Algorithms: In this systems, every entity(file) and peer are assigned a unique key by a hash function. The keys along with the network addresses of peer storing the files are evenly distributed among all participating peers. Each peer maintains a routing table and queries are forwarded to only those peers which are listed in the routing table.

    Sunday, May 29, 2005

    Need to exploit synergy

    Need for a decentralized and self organized discovery algorithm that can leverge with the servants and device migration.
    A tranformation algorithm which would make Nomadic to MANET, an algorithm that should exploit a synergy between P2P overlay networks and Mobile Ad-hoc Networks using an approach of Distributed Hash Table.

    Migration from Nomadic to MANET

    Does IOR distribution mechanism relates to p-p discovery algos, Flooding ,CAN, CHORD or Pastry? Nope, cuz as they are content algos, thats why they can work with Pure P-P and P-P with discovery.

    Entities MG, MH, and FC are workable in P-P environment? To start with, MH and FC are obviously different entities. But yeah, MHs and FCs can be combined to work in P-P envirnment.

    Do I require Discovery algorithms? Yes.

    Which discovery algorithm suits the framework well ?

    What after discovery? As they discover, then framework can go for Content based algorithms (in case services are different), and then go for IOR distribution. In case if services are same then framework can directly distribute the IOR.

    In process of servant migration, as the client IOR gets dirty, then in case of P-P or MANET how framework would manage the old IOR context?

    There requires a need for Async communication or real time message propagation

    Friday, May 06, 2005

    Ubicomputing Killer Apps

    Traffic Management Domain:
    • An accident warning service provided by a crashed car to approaching vehicles.
    • A warning service provided by an ambulance rushing to an accident side to inform nearby vehicles to yield the right of way.
    Business Domain:
    • A service provided by the lead of meeting to get poll information from attendes, registering the persons attending the meeting.
    Service Domain:
    • Personal information service hosted on PDAs.

    Sunday, April 24, 2005

    Common Characteristics of Discovery Mechanisms

    Common Characteristics:

    • Discovery Service (SLP is good)
    • Service Subtyping
    • Service Appearance and Disappearance: Highly dynamic updates in both service arrival and demise (except crash of service)
    • Service Browsing
    • Catalogs of Available services: UPnP is inherently P2P, hence doesn't require catalogs to be published, Jini publishes catalogs for clients, whereas SLP has both options.
    • Eventing
    • Garbage Collection: Leases are a popular garbage collection mechanism.

    Overviews:

    SLP:

    • User Agents(UA) search for needed services on behalf of clients.
    • Language Neutral.
    • (OpenSLP)

    UPnP:

    • Device and service descriptions are coded in XML.
    • UPnP does not support service directories - communication between devices and clients is always direct.
    • UPnP is aimed at smaller environments.
    • (UPnP SDK)

    Bluetooth:

    • Blutooth devices maintains sets of service records, each of which describes an available service.
    • Is lightweight , because it is meant for Personal Area Networks

    Saturday, April 23, 2005

    Peer to Peer and MANET

    mobile p2p systems are : self organising, fully decentralized, highly dynamic

    you have to tackle two issues : unstable connectivity, unpredictable IP addresses

    you have to predict the presence of peer, share configuration with peers and notice when they become unavailable

    peer discovery must be timely and efficient

    security aspects: must have encryption and robust authentication

    Tuesday, April 19, 2005

    Points

    Should approach for Mobile Ad-hoc Networks
    Use of Peer-to-Peer Computing
    Utilize the Service Discovery mechs like Own, UPnP, SLP or JXTA
    Intermediate use of own's Logical mobility mech and location tracking

    Tuesday, April 12, 2005

    Impromptu Service Discovery - JXTA, UPnP, SLP, JINI protocols

    Mobile server objects are quite similar to the work done in paper "proximity based service discovery in manet", feels great to work parallel work to Vinny.
    They have used event based middleware, to discover the services as of event producers.

    Friday, April 08, 2005

    9 Points Agenda - Works to be done

    • Impromptu Service Discovery - UPnP, JINI, SLP protocols
    • Minimal CORBA - low footprint
    • Asynchronous Behaviour - asynchronous messaging of request-responses, cache, use of CNS
    • Network Adaptation - access to MAC layer, adaptation according to MAC layer
    • Disconnection Operation - object by value, externalization and life cycle services, Use of mac layer for switching modes
    • Optimizing IIOP layer communication - analysis of architecture
    • Integration with Non- CORBA clients- SOAP, web service clients and others
    • Security Aspects- Authentication and Authorization services, security services
    • Early thoughts on Mobile ad-hoc networks - using Peer-to-Peer Computing

    Thursday, January 27, 2005

    Hello World !

    The most necessary and primary step that every programmer climbs many times but with different boots.