Wireless communication medium

• Unreliable
  • Disconnectable communication
  • Packet loss
• Latency
  • One-Way or Round Trip Time (RTT)
• Low data transfer rates
• Varying cost of communication
  • Location/ technology
• Extent of problems depends on utilised technology

• Connection between devices is lost
• Causes are:
  • Blocking elements - tunnel, buildings, magnetic fields
  • Gap /void in coverage area

• Problems
  • Did the action get through
    • Was the entire transaction successful
    • Is the customer/client aware?
  • What messages were lost?
  • What happens when the connection is re-established?
    • State of interuption stored
  • Negotiated connection closing
    • Two hill army/generals problem

Mobility management

• Seamless connectivity
• Vertical handoff - seamless connectivity with different technos
• Automatic failover from one medium to another to maintain connectivity

How does client/server application react?

• Can we affect the behaviour of both applications?
• How long to wait?

Missing packets

• Really short term disconnection

Causes:

• Interferences
• Congested medium - E.g. too many users of same frequency in small area

Problems

• Similar to disconnected communication to some degree
• Audio-Video stream heavily affected

Buffers could reduce/eliminate the problem

Remedies

• Non-blocking communications
  • Threading
  • Loss of network should not interrupt/deter writting email
• Use smaller packet size
  • Less retransmissions
• Use protocols that handle the problem for you

• Let the user know is going on - Enlighten
• Allow user to react
  • Thus can move to area with better coverage
• Not knowing why application has delays → users frustrations
• Frustration causes extreme measure
  • Repeated push of send button
  • Restart application
  • Reboot the device
• The environment (e.g. device capabilities) may reduce the options
• Anticipate connection loss at any time in your design phase!

• Delays between sending & receiving
  • Round trip time (RTT) between sending & getting response
• What affects latency
  • Distance
  • Amounts of hops
• What affects on RTT
  • Number of users on same base station (AP)
  • Processing of messages
  • Application latency
• Problems
  • Communication delays
  • Slow start on applications

• Slow satellite link
  • msg size = 1000 bits (frame), transmission speed 64kbit/s
  • signal speed == speed of light, distance 72 000 km (Geostationary satellites are at height of = 35,786 km),
  • sending one message thus takes 1 000 b / 64 000 b/s = 15.6 ms thus transmitting the signal takes 72000km/300000 km/s = 240 ms
  • getting ACK for data will thus take 240*2+15.6 ms +time for sending ack+time for handling the incoming data before sending ACK. ~ 0.5s
  • Even if we forget the message handling overhead the sender will idle 480/480+15.6 ~ 97% of the time. only 3% of channel is in use.

• Say No! to chatty protocols
  • E.g. HTTP 1.0 vs WTP
• Avoid unnecesary waits for ACKs and other responses
• Piggybacking
  • Sending and handling ACK PDU's causes overhead.
  • When data is sent both ways, the ACK message can be sent along the data (e.g. piggyback the data PDU)
  • Sending ACK can wait until there is actual data to be sent
    • Sent ACK can contain the serial number of last arrived packet and thus Acknowledges all packets to that point as arrived.
    • Postponing ACK sending too long will cause unnecessary retransmissions
    • Good to have timeouts for ACK sending to avoid lock situations.
      • Timer starts when packet to be acknowledged arrives.
• Remedies used for packet loss & intertuptions also help on latency issues

• Transmission rates vary a lot between technologies
• Causes communication delays
• Remedies
  • Minimise headers
  • Avoid unnecessary meta-data
    • Predetermined fields vs XML based notations
  • Reduce granularity of data (e.g no HD-images for mobile phone)
  • Use compression

• 3rd party networks
  • Charge service provider
  • Charge network user
  • Cost may vary depending on location
• Different models of charging on communication by 3rd parties
  • Time based
  • Data transmission based
  • Flat fee per connection
  • Flat fee per message (SMS)
• Recall creating your own infrastructure for a service is not free either

• Optimising
• Minimise
  • Battery use
  • Communication (overhead)
  • Amount of transmitted packets
  • External costs
• Maximise
  • Speed of application
  • User experience

• Best solution depends on platform & medium used
  • Which platform & mediums should be taken into account
  • Robust design
    • Can cope with problems of different possible communication mediums
  • Should data be compressed at mobile device before sending?
    • How will it take to compress?
    • How long will it take to transmit non-compressed data?

• Strive to reduce overheads
  • One connection vs. multiple connections
  • Send only required data
    • E.g. synchronisation - only data that has changed
    • Use cache
  • Smaller packets have higher overhead
    • Each packet has some headers
    • Bigger packets means bigger retransmission on error condition

• Efficient use of buffers
  • Place to store data while waiting for application to handled it
    • Small device CPU need more time to process data than desktop PCs
  • Packets ought be received even if application is not ready to use them
  • Decide who handles retransmissions
  • Custom make protocols E.g. Air link, transmission protocol, our application,..
  • Are retransmissions required?

• User's perception of the application
  • For small devices reducing the quality of picture is not perceivable
    • Faster transmission time appreciated
  • Give user control - (Empower)
    • On-line/Off-line modes
    • When to stop trying retransmissions
  • Provide the information about the current state

• Use existing protocol layers suited best for you & work the rest yourself
  • Use of standard protocols provides inter-operability
  • Use of existing protocols → reduce amount of coding
  • Existing protocols may cause unnecessary overhead
    • E.g Web services
  • Existing protocols may not be optimised for your services
    • Find the best compromise for your needs between work & efficiency

• IP
  • Connectionless protocol
  • Transports packets through several nodes to the destination
    • Is it needed when we have direct point-to-point connection between two devices?
  • IP v4 → insufficient address for entire mobile world (32bits → 4.3×10^9 = 4.3 Billion )
    • 02.2010 estimates 4.6 Billon mobile phones world wide
    • IP v6 is there waiting to be adopted (128bit → 3.4×10^38 = 340 trillion )
  • Mobility & handover are problems for IP
    • Mobile IP → mobility management course

• TCP
  • High latency is a problem
  • Wireless RTT can be seconds
  • Initial re-transmission time-out (IRTO)
    • Many Internet servers demand this to in hundred of milliseconds
    • IETF recommends 3 seconds
  • Provides reliable transmission between two applications
    • Lost packets detected by time-outs & acknowledgements (ACKS)
    • Causes end-to-end retransmissions instead of just retransmission over 1 link
      • Lower layer may assist on this
  • High latency requires higher time-outs

• TCP …
  • Flow control & congestion
    • Lost packet is a sign of congestion
      • In wireless lost packets are more common & not neccesarily signs of congestion
    • Retransmission & congestion control activated
    • Slow start
      • Sending window is extended slowly when packets get through
  • Openning a session requires 3 messages
    • Size of transmission window reduced
      • Slow start started again
    • TCP reduces the transmission speed → smaller packets → more overhead