Mobile Ad Hoc Networks (Manets) Are Wireless Networks Which Are Characterized by Dynamic
Mobile Ad Hoc Networks (Manets) Are Wireless Networks Which Are Characterized by Dynamic
UNIT-6
Mobile Ad hoc NETworks (MANETs) are wireless networks which are characterized by dynamic
topologies and no fixed infrastructure. Each node in a MANET is a computer that may be required
to act as both a host and a router and, as much, may be required to forward packets between
nodes which cannot directly communicate with one another. Each MANET node has much smaller
frequency spectrum requirements that that for a node in a fixed infrastructure network. A
MANET is an autonomous collection of mobile users that communicate over relatively bandwidth
constrained wireless links. Since the nodes are mobile, the network topology may change rapidly
and unpredictably over time. The network is decentralized, where all network activity including
discovering the topology and delivering messages must be executed by the nodes themselves,
i.e., routing functionality will be incorporated into mobile nodes.
A mobile ad hoc network is a collection of wireless nodes that can dynamically be set up
anywhere and anytime without using any pre-existing fixed network infrastructure.
MANET- Characteristics
Dynamic network topology
Bandwidth constraints and variable link capacity
Energy constrained nodes
Multi-hop communications
Limited security
Autonomous terminal
Distributed operation
Light-weight terminals
Need for Ad Hoc Networks
Setting up of fixed access points and backbone infrastructure is not
always viable
– Infrastructure may not be present in a disaster area or war zone
– Infrastructure may not be practical for short-range radios; Bluetooth (range ~ 10m)
Properties of MANETs
MANET enables fast establishment of networks. When anew network is to be established,
the only requirement is to provide a new set of nodes with limited wireless communication
range. A node has limited capability, that is, it can connect only to the nodes which are
nearby. Hence it consumes limited power.
A MANET node has the ability to discover a neighboring node and service. Using a service
discovery protocol, a node discovers the service of a nearby node and communicates to a
remote node in the MANET.
MANET nodes have peer-to-peer connectivity among themselves.
MANET nodes have independent computational, switching (or routing), and communication
capabilities.
The wireless connectivity range in MANETs includes only nearest node connectivity.
The failure of an intermediate node results in greater latency in communicating with the
remote server.
Limited bandwidth available between two intermediate nodes becomes a constraint for the
MANET. The node may have limited power and thus computations need to be energy-
efficient.
There is no access-point requirement in MANET. Only selected access points are provided for
connection to other networks or other MANETs.
MANET nodes can be the iPods, Palm handheld computers, Smart phones, PCs, smart labels,
smart sensors, and automobile-embedded systems\
MANET nodes can use different protocols, for example, IrDA, Bluetooth, ZigBee, 802.11,
GSM, and TCP/IP.MANET node performs data caching, saving, and aggregation.
MANET mobile device nodes interact seamlessly when they move with the nearby wireless nodes, sensor
nodes, and embedded devices in automobiles so that the seamless connectivity is maintained between
the devices.
MANET challenges
To design a good wireless ad hoc network, various challenges have to be taken into account:
Dynamic Topology: Nodes are free to move in an arbitrary fashion resulting in the topology
changing arbitrarily. This characteristic demands dynamic configuration of the network.
Limited security: Wireless networks are vulnerable to attack. Mobile ad hoc networks are
Applications of MANETS
The set of applications for MANETs is diverse, ranging from small, static networks that are
constrained by power sources, to large-scale, mobile, highly dynamic networks. The design of
network protocols for these networks is a complex issue. Regardless of the application, MANETs
need efficient distributed algorithms to determine network organization, link scheduling, and
routing. Some of the main application areas of MANET’s are:
• Military battlefield– soldiers, tanks, planes. Ad- hoc networking would allow the
military to take advantage of commonplace network technology to maintain an
information network between the soldiers, vehicles, and military information
headquarters.
Routing in MANET’s
Routing in Mobile Ad hoc networks is an important issue as these networks do not have
fixed infrastructure and routing requires distributed and cooperative actions from all nodes in the
network. MANET’s provide point to point routing similar to Internet routing. The major difference
between routing in MANET and regular internet is the route discovery mechanism. Internet
routing protocols such as RIP or OSPF have relatively long converge times, which is acceptable for
a wired network that has infrequent topology changes. However, a MANET has a rapid topology
changes due to node mobility making the traditional internet routing protocols inappropriate.
MANET-specific routing protocols have been proposed, that handle topology changes well, but
they have large control overhead and are not scalable for large networks. Another major
difference in the routing is the network address. In internet routing, the network address (IP
address) is hierarchical containing a network ID and a computer ID on that network. In contrast,
for most MANET’s the network address is simply an ID of the node in the network and is not
hierarchical. The routing protocol must use the entire address to decide the next hop.
Some of the fundamental differences between wired networks & ad-hoc networks are:
• Asymmetric links: - Routing information collected for one direction is of no use for the other
direction. Many routing algorithms for wired networks rely on a symmetric scenario.
• Redundant links: - In wired networks, some redundancy is present to survive link failures and
• Hybrid algorithms: maintain routes to nearby nodes even if they are not needed
and maintain routes to far away nodes only when needed. Example is Zone
Routing Protocol (ZRP).
Which approach achieves a better trade-off depends on the traffic and
mobilitypatterns.
Route Reply can be sent by reversing the route in Route Request (RREQ) only if links are
guaranteed to be bi-directional. If Unidirectional (asymmetric) links are allowed, then RREP may
need a route discovery from S to D. Node S on receiving RREP, caches the route included in the
RREP. When node S sends a data packet to D, the entire route is included in the packet header
{hence the name source routing}. Intermediate nodes use the source route included in a packet
to determine to whom a packet should be forwarded.
J sends a route error to S along route J-F-E-S when its attempt to forward the data packet S
(with route SEFJD) on J-D fails. Nodes hearing RERR update their route cache to remove link J-D
Advantages of DSR:
Routes maintained only between nodes who need to communicate-- reduces overhead
of route maintenance
Route caching can further reduce route discovery overhead
A single route discovery may yield many routes to the destination, due to intermediate
nodes replying from local caches
Disadvantages of DSR:
Packet header size grows with route length due to source routing
Flood of route requests may potentially reach all nodes in the network
Care must be taken to avoid collisions between route requests propagated by
neighboring nodes -- insertion of random delays before forwarding RREQ
Increased contention if too many route replies come back due to nodes replying using
their local cache-- Route Reply Storm problem. Reply storm may be eased by preventing
a node from sending RREP if it hears another RREP with a shorter route
An intermediate node may send Route Reply using a stale cached route, thus polluting
other caches
An optimization for DSR can be done called as Route Caching. Each node caches a new route it
learns by any means. In the above example, When node S finds route [S,E,F,J,D] to node D,
node S also learns route [S,E,F] to node F. When node K receives Route Request [S,C,G]
destined for node, node K learns route [K,G,C,S] to node S. When node F forwards Route Reply
RREP [S,E,F,J,D], node F learns route [F,J,D] to node D. When node E forwards Data [S,E,F,J,D] it
learns route [E,F,J,D] to node D. A node may also learn a route when it overhears Data packets.
Usage of Route cache can speed up route discovery and can also reduce propagation of route
When node X is unable to forward packet P (from node S to node D) on link (X,Y), it generates a
RERR message Node X increments the destination sequence number for D cached at node X.
The incremented sequence number N is included in the RERR. When node S receives the RERR,
it initiates a new route discovery for D using destination sequence number at least as large as
N. When node D receives the route request with destination sequence number N, node D will
set its sequence number to N, unless it is already larger than N.
Neighboring nodes periodically exchange hello message and absence of hello message indicates
a link failure. When node X is unable to forward packet P (from node S to node D) on link (X,Y),
it generates a RERR message. Node X increments the destination sequence number for D
cached at node X. The incremented sequence number N is included in the RERR. When node S
receives the RERR, it initiates a new route discovery for D using destination sequence number
at least as large as N. When node D receives the route request with destination sequence
number N, node D will set its sequence number to N, unless it is already larger than N.
Another example for AODV protocol:
Assume node-1 want to send a msg to node-14 and does not know the route. So, it broadcasts
(floods) route request message, shown in red.
Node from which RREQ was received defines a reverse route to the source. (reverse routing
table entries shown in blue).
The route request is flooded through the network. Destination managed sequence number, ID
prevent looping. Also, flooding is expensive and creates broadcast collision problem.
Route request arrives at the destination node-14. Upon receiving, destination sends route reply
by setting a sequence number(shown in pink)
Routing table now contains forward route to the destination. Route reply follows reverse route
back to the source.
Once the route reply reaches the source, it adopts the destination sequence number. Traffic
flows along the forward route. Forward route is refreshed and the reverse routes get timedout.
Suppose there has been a failure in one of the links. The node sends a return error message to
the source with incrementing the sequencenumber.
Once the source receives the route error, it re-initiates the route discoveryprocess.
The cluster structure leads to a higher performance of the routing protocol as compared to
other protocols because it provides gateway switch-type traffic redirections and clusters
provide an effective membership of nodes for connectivity.
CGSR works as follow:
• periodically, every nodes sends a hello message containing its ID and a monotonically
increasing sequence number
The multipoint relays of each node, (MPR), is the minimal set of 1-hop nodes that covers all 2- hop
points.
• The members of the MPR are the only nodes that can retransmit the link state information
in an attempt to limit the flood.
Security in MANET’s
Securing wireless ad-hoc networks is a highly challenging issue. Understanding possible form of
attacks is always the first step towards developing good security solutions. Security of
communication in MANET is important for secure transmission of information. Absence of any
central co-ordination mechanism and shared wireless medium makes MANET more vulnerable
The Wireless Application Protocol (WAP) is an open, global specification that empowers mobile
users with wireless devices to easily access and interact with information and services instantly.
WAP is a global standard and is not controlled by any single company. Ericsson, Nokia,
Motorola, and Unwired Planet founded the WAP Forum in the summer of 1997 with the initial
purpose of defining an industry-wide specification for developing applications over wireless
communications networks. The WAP specifications define a set of protocols in application,
session, transaction, security, and transport layers, which enable operators, manufacturers, and
applications providers to meet the challenges in advanced wireless service differentiation and
fast/flexible service creation.
In the past, wireless Internet access has been limited by the capabilities of handheld devices
and wireless networks.
WAP utilizes Internet standards such as XML, user datagram protocol (UDP), and Internet
protocol (IP). Many of the protocols are based on Internet standards such as hypertext
transfer protocol (HTTP) and TLS but have been optimized for the unique constraints of the
wireless environment: low bandwidth, high latency, and less connection stability.
Internet standards such as hypertext markup language (HTML), HTTP, TLS and transmission
control protocol (TCP) are inefficient over mobile networks, requiring large amounts of
mainly text-based data to be sent. Standard HTML content cannot be effectively displayed
on the small-size screens of pocket-sized mobile phones and pagers.
WAP utilizes binary transmission for greater compression of data and is optimized for long
latency and low bandwidth. WAP sessions cope with intermittent coverage and can operate
over a wide variety of wireless transports.
WAP will provide multiple applications, for business and customer markets such as banking,
corporate database access, and a messaging interface.
WAP Architecture
The following figure gives an overview of the WAP architecture, its protocols and
components, and compares this architecture with the typical internet architecture when using
the World Wide Web. The basis for transmission of data is formed by different bearer services.
WAP does not specify bearer services, but uses existing data services and will integrate further
services. Examples are message services, such as short message service (SMS) of GSM, circuit-
switched data, such as high-speed circuit switched data (HSCSD) in GSM, or packet switched
data, such as general packet radio service (GPRS) in GSM. Many other bearers are supported,
such as CDPD, IS-136, PHS.
The WAP datagram protocol (WDP) and the additional Wireless control message protocol
(WCMP) is the transport layer that sends and receives messages via any available bearer
network, including SMS, USSD, CSD, CDPD, IS–136 packet data, and GPRS. The transport layer
WTLS: The next higher layer, the security layer with its wireless transport layer security protocol
WTLS offers its service at the security SAP (SEC-SAP). WTLS is based on transport layer security
(TLS, formerly SSL, secure sockets layer). WTLS has been optimized for use in wireless networks
with narrow-band channels. It can offer data integrity, privacy, authentication, and (some)
denial-of-service protection.
WTP: The WAP transaction protocol (WTP) layer provides transaction support, adding reliability
to the datagram service provided by WDP at the transaction SAP(TR-SAP).
WSP: The session layer with the wireless session protocol (WSP) currently offers two services at
the session-SAP (S-SAP), one connection-oriented and one connectionless if used directly on
top of WDP. A special service for browsing the web (WSP/B) has been defined that offers
HTTP/1.1 functionality, long-lived session state, session suspend and resume, session migration
and other features needed for wireless mobile access to the web.
WAE: The application layer with the wireless application environment (WAE) offers a
framework for the integration of different www and mobile telephony applications.
Working of WAP
WAP does not always force all applications to use the whole protocol architecture. Applications
can use only a part of the architecture. For example, if an application does not require security
but needs the reliable transport of data, it can directly use a service of the transaction layer.
Simple applications can directly use WDP.
Different scenarios are possible for the integration of WAP components into existing wireless
and fixed networks. On the left side, different fixed networks, such as the traditional internet
and the public switched telephone network (PSTN), are shown. One cannot change protocols
and services of these existing networks so several new elements will be implemented between
these networks and the WAP-enabled wireless, mobile devices in a wireless network on the
right-hand side.
Wireless Datagram Protocol (WDP)
Wireless Datagram Protocol defines the movement of information from receiver to the sender
and resembles the User Datagram Protocol in the Internet protocol suite.
WDP offers a consistent service at the Transport Service Access Point to the upper layer
protocol of WAP. This consistency of service allows for applications to operate transparently
over different available bearer services. WDP can be mapped onto different bearers, with
different characteristics. In order to optimise the protocol with respect to memory usage and
radio transmission efficiency, the protocol performance over each bearer may vary.
WDP offers source and destination port numbers used for multiplexing and demultiplexing of
data respectively. The service primitive to send a datagram is TDUnitdata. req with the
destination address (DA), destination port (DP), Source address (SA), source port (SP), and
user data (UD) as mandatory parameters. Destination and source address are unique
addresses for the receiver and sender of the user data. These could be MSISDNs (i.e., a
telephone number), IP addresses, or any other unique identifiers. The T-DUnitdata.ind service
primitive indicates the reception of data. Here destination address and port are only optional
parameters.
WDP service primitives
If a higher layer requests a service the WDP cannot fulfil, this error is indicated with the
T-DError.ind service primitive. An error code (EC) is returned indicating the reason for the
error to the higher layer. WDP is not allowed to use this primitive to indicate problems with the
bearer service. It is only allowed to use the primitive to indicate local problems, such as a user
data size that is too large. If any errors happen when WDP datagrams are sent from one WDP
entity to another, the wireless control message protocol (WCMP) provides error handling
mechanisms for WDP and should therefore be implemented. WCMP contains control messages
that resemble the internet control message protocol messages and can also be used for
diagnostic and informational purposes. WCMP can be used by WDP nodes and gateways to
report errors.
WTLS can provide different levels of security (for privacy, data integrity, and
authentication) and has been optimized for low bandwidth, high-delay bearer networks. WTLS
takes into account the low processing power and very limited memory capacity of the mobile
devices for cryptographic algorithms. WTLS supports datagram and connection-oriented
transport layer protocols. WTLS took over many features and mechanisms from TLS, but it has
an optimized handshaking between the peers.
Before data can be exchanged via WTLS, a secure session has to be established. This session
establishment consists of several steps: The following figure illustrates the sequence of service
primitives needed for a so-called ‘full handshake’.
The first step is to initiate the session with the SEC-Create primitive. Parameters are source
address (SA), source port (SP) of the originator, destinationaddress (DA), destination port
(DP) of the peer. The originator proposes a key exchange suite (KES) (e.g., RSA, DH, ECC), a
cipher suite (CS) (e.g., DES, IDEA ), and a compression method (CM). The peer answers with
parameters for the sequence number mode (SNM), the key refresh cycle (KR) (i.e., how often
keys are refreshed within this secure session), the session identifier (SID) (which is unique with
each peer), and the selected key exchange suite (KES’), cipher suite (CS’), compression
method (CM’). The peer also issues a SEC-Exchange primitive. This indicates that the peer
wishes to perform public-key authentication with the client, i.e., the peer
After setting up a secure connection between two peers, user data can be exchanged. This is
done using the simple SEC-Unit data primitive as shown in above figure. SEC-Unit data has
exactly the same function as T-D Unit data on the WDP layer, namely it transfers a datagram
between a sender and a receiver. This data transfer is still unreliable, but is now secure. This
shows that WTLS can be easily plugged into the protocol stack on top of WDP.
WTP has been designed to run on very thin clients, such as mobile phones. WTP offers several
advantages to higher layers, including an improved reliability over datagram services, improved
efficiency over connection-oriented services, and support for transaction-oriented services such
as web browsing. WTP offers many features to the higher layers. The basis is formed from three
classes of transaction service. Class 0 provides unreliable message transfer without any result
message. Classes 1 and 2 provide reliable message transfer, class 1 without, class 2 with, exactly
one reliable result message (the typical request/response case). WTP achieves reliability using
duplicate removal, retransmission, acknowledgements and unique transaction
identifiers.WTP allows for asynchronous transactions, abort of transactions, concatenation
of messages, and can report success or failure of reliable messages (e.g., a server cannot
handle the request). The three service primitives offered by WTP are TR-Invoke to initiate a
new transaction, TR-Result to send back the result of a previously initiated transaction, and
TR- Abort to abort an existing transaction.
The PDUs exchanged between two WTP entities for normal transactions are the invoke PDU,
ack PDU, and result PDU. A special feature of WTP is its ability to provide a user
acknowledgement or, alternatively, an automatic acknowledgement by the WTPentity.WTP
Class 0
Class 0 offers an unreliable transaction service without a result message. The transaction is
stateless and cannot be aborted. The service is requested with the TR-Invoke.req primitive as
shown below. Parameters are same as in WDP.
Additionally, with the A flag, the user of this service can determine, if the responder WTP entity
should generate an acknowledgement or if a user acknowledgement should be used. The WTP
layer will transmit the user data (UD) transparently to its destination. The class type C
indicates here class 0. Finally, the transaction handle H provides a simple index to uniquely
identify the transaction and is an alias for the tuple (SA, SP, DA, DP), i.e., a socket pair, with only
local significance. The WTP entity at the initiator sends an invoke PDU which the responder
receives. The WTP entity at the responder then generates a TR-Invoke.ind primitive with the
same parameters as on the initiator’s side, except for H’ which is now the local handle for the
transaction on the responder’s side. WTP class 0 augments the transaction service with a simple
datagram like service for occasional use by higher layers.
WTP Class 1
Class 1 offers a reliable transaction service but without a result message. Again, the initiator
sends an invoke PDU after a TR-Invoke.req from a higher layer. This time, class equals ‘1’, and
no user acknowledgement has been selected as shown below.
The responder signals the incoming invoke PDU via the TR-Invoke.ind primitive to the higher
layer and acknowledges automatically without user intervention. For the initiator the
transaction ends with the reception of the acknowledgement. The responder keeps the
transaction state for some time to be able to retransmit the acknowledgement if it receives the
same invoke PDU again indicating a loss of the acknowledgement.If a user of the WTP class 1
service on the initiator’s side requests a user acknowledgement on the responder’s side, the
sequence diagram looks like the following figure.
Now the WTP entity on the responder’s side does not send an acknowledgement
automatically, but waits for the TR-Invoke.res service primitive from the user. This service
primitive must have the appropriate local handle H’ for identification of the right
transaction. The WTP entity can now send the ack PDU. Typical uses for this transaction
class are reliable push services.
WTP Class 2
class 2 transaction service provides the classic reliable request/response transaction known
from many client/server scenarios. Depending on user requirements, many different
scenarios are possible for initiator/responder interaction. Three examples are presented
below.
Example-1 scenario is shown below. A user on the initiator’s side requests the service and
In example-2, the user on the responder’s side now explicitly responds to the Invoke PDU using
the TR-Invoke.res primitive, which triggers the TR-Invoke.cnf on the initiator’s side via an
ack PDU. The transmission of the result is also a confirmed service, as indicated by the next
four service primitives. This service will likely be the most common in standard
request/response scenarios as, e.g., distributed computing. of the result takes some time, the
responder can put the initiator on “hold on” to prevent a retransmission of the invoke PDU as
the initiator might assume packet loss if no result is sent back within a certain timeframe, which
is shown above. After a time-out, the responder automatically generates an acknowledgement
for the Invoke PDU. This shows the initiator that the responder is still alive and currently busy
processing the request. After more time, the result PDU can be sent to the initiator.
Wireless Session Protocol (WSP)
The wireless session protocol (WSP) has been designed to operate on top of the
datagram service WDP or the transaction service WTP. WSP provides a shared state between a
client and a server to optimize content transfer. WSP offers the following general features
needed for content exchange between cooperating clients and servers:
Session management: WSP introduces sessions that can be established from a client to
a server and may be long lived. Sessions can also be released in an orderly manner. The
capabilities of suspending and resuming a session are important to mobile applications.
Capability negotiation: Clients and servers can agree upon a common level of protocol
functionality during session establishment. Example parameters to negotiate are
maximum client SDU size, maximum outstanding requests, protocol options, and server
SDU size.
Content encoding: WSP also defines the efficient binary encoding for the content it
transfers. WSP offers content typing and composite objects, as explained for web
browsing.
CH SATYANARAYANA Asst. Professor
UNIT-6 MOBILE COMPUTING
While WSP is a general-purpose session protocol, WAP has specified the wireless session
protocol/browsing (WSP/B) which comprises protocols and services most suited for browsing-
type applications, which offers the following features adapted to web browsing.
WSP/B uses the three service classes of WTP where, Class 0 is used for unconfirmed push,
session resume, and session management. Confirmed push uses class 1, method invocation,
session resume, and session management class 2.
The first example of session establishment of WSP/B using WTS class 2 transactions
With the S-Connect.req primitive, a client can request a new session. Parameters are the
server address (SA), the client address (CA), and the optional client header (CH) and
requested capabilities (RC). The session layer directly uses the addressing scheme of the layer
below. WTP transfers the connect PDU to the server S-SAP where an S-Connect.ind primitive
indicates a new session. Parameters are the same, but now the capabilities are mandatory. If
the server accepts the new session it answers with an S-Connect.res, parameters are an
optional server header (SH) with the same function as the client header and the negotiated
capabilities (NC) needed for capability negotiation. WTP now transfers the connreply PDU
back to the client; S-Connect.cnf confirms the session establishment and includes the server
header (if present) and the negotiated capabilities from the server. WSP/B includes several
procedures to refuse a session or to abort session establishment.
A very useful feature of WSP/B session suspension and session resume is shown below. A
client can suspend the session because of several reasons. Session suspension will automatically
abort all data transmission and freeze the current state of the session on the client and server
side. A client suspends a session with S-Suspend.req, WTP transfers the suspend PDU to the
server with a class 0 transaction, i.e., unconfirmed and unreliable. WSP/B will signal the
suspension with S-Suspend.ind on the client and server side. The only parameter is the reason
R for suspension. Reasons can be a user request or a suspension initiated by the service
provider.
Also shown above that, a client can later resume a suspended session with S-Resume.req.
Parameters are server address (SA) and client address (CA). Resuming a session is a
confirmed operation. It is up to the server’s operator how long this state is conserved.
Terminating a session is done by using the S-Disconnect.req service primitive as shown below.
This primitive aborts all current method or push transactions used to transfer data.
Disconnection is indicated on both sides using S-Disconnect.ind. The reason R for
disconnection can be, e.g., network error, protocol error, peer request, congestion, and
maximum SDU size exceeded.
The S-Method Invoke primitive is used to request that an operation is executed by the server.
The result, if any, is sent back using the S-Method Result primitive.
On the server’s side, S-MethodInvoke.ind indicates the request. In this case, a server
transaction identifier STID distinguishes between pending transactions. The server confirms
the request, so WSP/B does not generate a new PDU but relies on the lower WTP layer.
Similarly, the result of the request is sent back to the client using the SMethod Result
primitive. Additional parameters are now the status (S), the response header (RH), and the
response body (RB).
WSP does not introduce PDUs or service primitives just for the sake of symmetric and
aesthetic protocol architecture. The following figure shows how WSP (thus also WSP/B) uses
the underlying WTP services for its purposes. The S-MethodInvoke.req primitive triggers the
TR- Invoke.req primitive, the parameters of the WSP layer are the user data of the WTP layer.
The invoke PDU of the WTP layer carries the method PDU of the WSP layer inside.
For the confirmation of its service primitives the WSP layer has none of its own PDUs but uses
the acknowledgement PDUs of the WTP layer. S-MethodInvoke.res triggers TR-Invoke.res,
the ack PDU is transferred to the initiator, here TR-Invoke.cnf confirms the invoke service
and triggers the S-MethodInvoke.cnf primitive which confirms the method invocation service.
This mingling of layers saves a lot of redundant data flow but still allows a separation of the
tasks between the two layers.
With the help of push primitives, a server can push data towards a client if allowed. The
simplest push mechanism is the non-confirmed. The server sends unsolicited data with the S-
Push.req primitive to the client. Parameters are the push header (PH) and the push body
(PB) again, these are the header and the body known from HTTP. The unreliable, unconfirmed
WTP class 0 transaction service transfers the push PDU to the client where S-Push.ind
indicates the push event. Here the server has to determine the push using a server push
identifier (SPID). This helps to distinguish between different pending pushes. The reliable WTP
class 1 transaction service is now used to transfer the conf push PDU to the client. On the
client’s side a client push identifier (CPID) is used to distinguish between different pending
pushes.
WSP/B could be run on top of the connectionless, unreliable WDP service. As an alternative to
WDP, WTLS can always be used if security is required. The service primitives are directly
mapped onto each other. The following figure shows the three service primitives available for
connectionless session service: S-Unit-MethodInvoke.req to request an operation on a server,
S-Unit-MethodResult.req to return results to a client, and S-Unit-Push.req to push data onto
a client. Transfer of the PDUs (method, reply and push) is done with the help of the standard
unreliable datagram transfer service of WDP.
Besides the server address (SA), the client address (CA), the method (M), and the
request URI (RU), the user of the S-Unit-MethodInvoke.req primitive can determine a
transaction identifier (TID) to distinguish between different transactions on the user level. TID
is communicated transparently from service user to service user.
The function of the S-Unit-Method Result primitive remains the same as explained
above: the status (S), response header (RH), and response body (RB) represent the result of
the operation. The S-Unit-Push primitive has the parameters client address (CA), server
address (SA), push identifier (PID), push header (PH), and push body (PB).
The origin servers will respond to the request. The gateway now encodes the response
and its content (if there is any) and transfers the encoded response with the content to the
client. The WAE logical model not only includes this standard request/response scheme, but it
also includes push services. Then an origin server pushes content to the gateway. The gateway
encodes the pushed content and transmits the encoded push content to the client. Several user
agents can reside within a client. User agents include such items as: browsers, phonebooks,
message editors etc. WAE does not specify the number of user agents or their functionality, but
assumes a basic WML user agent that supports WML, WMLscript, or both (i.e., a ‘WML
browser’). However, one more user agent has been specified with its fundamental services, the
WTA user agent. This user agent handles access to, and interaction with, mobile telephone
features (such as call control). As over time many vendor dependent user agents may develop,
the standard defines a user agent profile (UAProf), which describes the capabilities of a user
agent.
The wireless markup language (WML) is based on the standard HTML known from the www
and on HDML. WML is specified as an XML document type. Several constraints of wireless
handheld devices had to be taken into account, when designing WML.
WML follows a deck and card metaphor. A WML document is made up of multiple cards. Cards
can be grouped together into a deck. A WML deck is similar to an HTML page, in that it is
identified by a URL and is the unit of content transmission. A user navigates with the WML
browser through a series of WML cards, reviews the contents, enters requested data, makes
choices etc. The WML browser fetches decks as required from origin servers. Either these decks
can be static files on the server or they can be dynamically generated.WML describes the intent
of interaction in an abstract manner. The user agent on a handheld device has to decide how to
WML script
WMLScript complements to WML and provides a general scripting capability in the WAP
architecture. While all WML content is static (after loading on the client), WMLScript offers
several capabilities not supported by WML:
Validity check of user input: before user input is sent to a server, WMLScript can check
the validity and save bandwidth and latency in case of an error.
Access to device facilities: WMLScript offers functions to access hardware components and
software functions of the device.
Local user interaction: Without introducing round-trip delays, WMLScript can directly and
locally interact with a user, show messages or prompt for input.
Extensions to the device software: With the help of WMLScript a device can be configured
and new functionality can be added even after deployment.
"Bluetooth" was the nickname of Harald Blåtland II, king of Denmark from 940 to 981, who
united all of Denmark and part of Norway under his rule. Bluetooth is a proprietary open
wireless technology standard for exchanging data over short distances (using short wavelength
radio transmissions in the ISM band from 2400-2480 MHz) from fixed and mobile devices,
creating personal area networks (PANs) with high levels of security. The Bluetooth technology
aims at so-called ad-hoc piconets, which are local area networks with a very limited coverage
and without the need for an infrastructure.
Bluetooth Features
Bluetooth is wireless and automatic. You don't have to keep track of cables, connectors, and
connections, and you don't need to do anything special to initiate communications. Devices
find each other automatically and start conversing without user input, expect where
authentication is required; for example, users must log in to use their email accounts.
Bluetooth is inexpensive. Market analysts peg the cost to incorporate Bluetooth technology
into a PDA, cell phone, or other product at a minimum cost.
The ISM band that Bluetooth uses is regulated, but unlicensed. Governments have
converged on a single standard, so it's possible to use the same devices virtually wherever
you travel, and you don't need to obtain legal permission in advance to begin using the
technology.
Bluetooth handles both data and voice. Its ability to handle both kinds of transmissions
simultaneously makes possible such innovations as a mobile hands-free headset for voice
with applications that print to fax, and that synchronize the address books on your PDA,
your laptop, and your cell phone.
Signals are omni-directional and can pass through walls and briefcases. Communicating
devices don't need to be aligned and don't need an unobstructed line of sight likeinfrared.
Bluetooth uses frequency hopping. Its spread spectrum approach greatly reduces the risk
that communications will be intercepted.
Bluetooth Applications
File transfer.
Ad-hoc networking: Communicating devices can spontaneously form a community of
networks that persists only as long as it's needed
The 802.11b protocol is designed to connect relatively large devices with lots of power and
speed, such as desktops and laptops, where devices communicate at up to 11 Mbit/sec, at
greater distances (up to 300 feet, or 100 meters). By contrast, Bluetooth is designed to connect
small devices like PDAs, mobile phones, and peripherals at slower speeds (1 Mbit/sec), within a
shorter range (30 feet, or 10 meters), which reduces power requirements. Another major
difference is that 802.11b wasn't designed for voice communications, while any Bluetooth
connection can support both data and voicecommunications.
User scenarios
Many different user scenarios can be imagined for wireless piconets or WPANs:
Connection of peripheral devices: Today, most devices are connected to a desktop computer
via wires (e.g., keyboard, mouse, joystick, headset, speakers). This type of connection has
several disadvantages: each device has its own type of cable, different plugs are needed, wires
block office space. In a wireless network, no wires are needed for data transmission. However,
batteries now have to replace the power supply, as the wires not only transfer data but also
supply the peripheral devices with power.
Support of ad-hoc networking: Imagine several people coming together, discussing issues,
exchanging data (schedules, sales figures etc.). For instance, students might join a lecture, with
the teacher distributing data to their personal digital assistants (PDAs). Wireless networks can
support this type of interaction; small devices might not have WLAN adapters following the IEEE
802.11 standard, but cheaper Bluetooth chips built in.
Bridging of networks: Using wireless piconets, a mobile phone can be connected to a PDA or
laptop in a simple way. Mobile phones will not have full WLAN adapters built in, but could have
a Bluetooth chip. The mobile phone can then act as a bridge between the local piconet and,
e.g., the global GSM network.
Parked devices (P) can not actively participate in the piconet (i.e., they do not have a
connection), but are known and can be reactivated within some milliseconds. Devices in stand-
by (SB) do not participate in the piconet. Each piconet has exactly one master and up to seven
simultaneous slaves. More than 200 devices can be parked. The first step in forming a piconet
involves a master sending its clock and device ID. All the Bluetooth devices have the same
capability to become a master or a slave and two or three devices are sufficient to form a
piconet. The unit establishing the piconet automatically becomes the master, all other devices
will be slaves. The hopping pattern is determined by the device ID, a 48-bit worldwide unique
identifier.
The phase in the hopping pattern is determined by the master’s clock. After adjusting
the internal clock according to the master a device may participate in the piconet. All active
devices are assigned a 3-bit active member address (AMA). All parked devices use an 8-bit
parked member address (PMA). Devices in stand-by do not need an address.
The radio layer is the physical wireless connection. To avoid interference with other devices
that communicate in the ISM band, the modulation is based on fast frequency hopping.
Bluetooth divides the 2.4 GHz frequency band into 79 channels 1 MHz apart (from 2.402 to
2.480 GHz), and uses this spread spectrum to hop from one channel to another, up to 1600
The baseband layer is responsible for controlling and sending data packets over the radio
link. It provides transmission channels for both data and voice. The baseband layer
maintains Synchronous Connection-Oriented (SCO) links for voice and Asynchronous
Connectionless (ACL) links for data. SCO packets are never retransmitted but ACL packets
are, to ensure data integrity. SCO links are point-to-point symmetric connections, where
time slots are reserved to guarantee timely transmission. A slave device is allowed to
respond during the time slot immediately following an SCO transmission from the master. A
master can support up to three SCO links to a single slave or to multiple slaves, and a single
slave can support up to two SCO links to different slaves. Data transmissions on ACL links,
on the other hand, are established on a per-slot basis (using slots not reserved for SCO
links). ACL links support point-to-multipoint transmissions. After an ACL transmission from
the master, only a slave addressed specifically may respond during the next time slot; if no
device is addressed, the message is treated as a broadcast.
The Link Manager Protocol (LMP) uses the links set up by the baseband to establish
connections and manage piconets. Responsibilities of the LMP also include authentication
and security services, and monitoring of service quality.
The Host Controller Interface (HCI) is the dividing line between software and hardware. The
L2CAP and layers above it are currently implemented in software, and the LMP and lower
layers are in hardware. The HCI is the driver interface for the physical bus that connects
these two components. The HCI may not be required. The L2CAP may be accessed
directlyby the application, or through certain support protocols provided to ease the burden
on application programmers.
The Logical Link Control and Adaptation Protocol (L2CAP) receives application data and
adapts it to the Bluetooth format. Quality of Service (QoS) parameters are exchanged at this
layer.
Link Manager Protocol
The link manager protocol (LMP) manages various aspects of the radio link between a master
and a slave and the current parameter setting of the devices. LMP enhances baseband
functionality, but higher layers can still directly access the baseband. The following groups of
functions are covered by the LMP:
A device wants to establish a piconet: A user of the device wants to scan for other
devices in the radio range. The device starts the inquiry procedure by sending an inquiry
access code (IAC) that is common to all Bluetooth devices. The IAC is broadcast over 32
so-called wake-up carriers in turn.
Devices in standby that listen periodically: Devices in standby may enter the inquiry
mode periodically to search for IAC messages on the wake-up carriers. As soon as a
device detects an inquiry it returns a packet containing its device address and timing
information required by the master to initiate a connection. From that moment on, the
device acts as slave.
If the inquiry was successful, a device enters the page mode. The inquiry phase is not
coordinated, so it may take a while before the inquiry is successful. After a while, a Bluetooth
device sees all the devices in its radio range.
Sniff state: The sniff state has the highest power consumption of the low power states.
Here, the device listens to the piconet at a reduced rate (not on every other slot as is the
case in the active state). The interval for listening into the medium can be programed and is
application dependent. The master designates a reduced number of slots for transmission
to slaves in sniff state. However, the device keeps its AMA.
Hold state: The device does not release its AMA but stops ACL transmission. A slave may
still exchange SCO packets. If there is no activity in the piconet, the slave may either reduce
power consumption or participate in another piconet.
Park state: In this state the device has the lowest duty cycle and the lowest power
consumption. The device releases its AMA and receives a parked member address (PMA).
The device is still a member of the piconet, but gives room for another device to become
active (AMA is only 3 bit, PMA 8 bit). Parked devices are still FH synchronized and wake up
at certain beacon intervals for re-synchronization. All PDUs sent to parked slaves are
broadcast.
L2CAP
The logical link control and adaptation protocol (L2CAP) is a data link control protocol on top of
the baseband layer offering logical channels between Bluetooth devices with QoS properties.
L2CAP is available for ACLs only.
L2CAP provides three different types of logical channels that are transported via the ACL
between master and slave:
Connectionless: These unidirectional channels are typically used for broadcasts from a
master to its slave(s).
Connection-oriented: Each channel of this type is bi-directional and supports QoS flow
specifications for each direction. These flow specs follow RFC 1363 and define average/peak
data rate, maximum burst size, latency, and jitter.
Each channel can be identified by its channel identifier (CID). Signaling channels always use a
CID value of 1, a CID value of 2 is reserved for connectionless channels. For connection-oriented
channels a unique CID (>= 64) is dynamically assigned at each end of the channel to identify the
connection.
The following figure shows the three packet types belonging to the three logical channel types.
The length field indicates the length of the payload (plus PSM for connectionless PDUs). The
CID has the multiplexing/demultiplexing function. For connectionless PDUs a protocol/service
multiplexor (PSM) field is needed to identify the higher layer recipient for the payload. For
connection-oriented PDUs the CID already fulfills this function. Several PSM values have been
defined, e.g., 1 (SDP), 3 (RFCOMM), 5 (TCS-BIN). Values above 4096 can be assigned
dynamically. The payload of the signaling PDU contains one or more commands. Each
command has its own code (e.g., for command reject, connection request, disconnection
response etc.) and an ID that matches a request with its reply. The length field indicates the
length of the data field for this command.
Besides protocol multiplexing, flow specification, and group management, the L2CAP layer also
provides segmentation and reassembly functions. Depending on the baseband capabilities,
large packets have to be chopped into smaller segments.
All Bluetooth-enabled devices must implement the Generic Access Profile, which contains all
the Bluetooth protocols and possible devices. This profile defines a security model that includes
three security modes:
Though Bluetooth offers a better security than WER in 802.11, it has several limitations. The
PIN’s are often fixed and some keys are permanently stored on the devices. The quality of the
random number generators has not been specified.
SDP
To find new services available in the radio proximity, Bluetooth defined the service discovery
protocol (SDP). SDP defines only the discovery of services, not their usage. Discovered services
can be cached and gradual discovery is possible. All the information an SDP server has about a
service is contained in a service record. This consists of a list of service attributes and is
identified by a 32-bit service record handle.
A service attribute consists of an attribute ID and an attribute value. The 16-bit attribute
ID distinguishes each service attribute from other service attributes within a service record. The
attribute ID also identifies the semantics of the associated attribute value. The attribute value
can be an integer, a UUID (universally unique identifier), a string, a Boolean, a URL (uniform
resource locator) etc.
The following basic profiles have been specified: generic access, service discovery, cordless
telephony, intercom, serial port, headset, dialup networking, fax, LAN access, generic object
exchange, object push, file transfer, and synchronization. Additional profiles are: advanced
audio distribution, PAN, audio video remote control, basic printing, basic imaging, extended
service discovery, generic audio video distribution, hands-free, and hardcopy cable
replacement. Some of the profiles are given below:
The Generic Access Profile defines connection procedures, device discovery, and link
management. It also defines procedures related to use of different security models and
common format requirements for parameters accessible on the user interface level. At a
minimum all Bluetooth devices must support this profile.
The Service Discovery Application and Profile defines the features and procedures for an
application in a Bluetooth device to discover services registered in other Bluetooth devices,
and retrieves information related to the services.
The Serial Port Profile defines the requirements for Bluetooth devices that need to set up
connections that emulate serial cables and use the RFCOMM protocol.
The LAN Access Profile defines how Bluetooth devices can access the services of a LAN using
PPP, and shows how PPP mechanisms can be used to form a network consisting of
Bluetooth devices.
While connected consumer devices such as cell phones, pagers, personal organizers and set-top
boxes have many things in common, they are also diverse in form, function and features.
Information appliances tend to be special-purpose, limited-function devices. To address this
diversity, an essential requirement for J2ME is not only small size but also modularity and
customizability. The J2ME architecture is modular and scalable so that it can support the kinds
of flexible deployment demanded by the consumer and embedded markets. To support this
kind of customizability and extensibility, two essential concepts are defined by J2ME:
Configurations
A configuration is a subset of profile. A configuration defines a Java platform for a “horizontal”
category or grouping of devices with similar requirements on total memory budget and other
hardware capabilities. More specifically, aconfiguration:
Connected, Limited Device Configuration (CLDC). The market consisting of personal, mobile,
connected information devices is served by the CLDC. This configuration includes some new
classes, not drawn from the J2SE APIs, designed specifically to fit the needs of small-footprint
devices. It is used specifically with the KVM for 16-bit or 32-bit devices with limited amounts of
memory. This is the configuration (and the virtual machine) used for developing small J2ME
applications.
Connected Device Configuration (CDC). The market consisting of shared, fixed, connected
information devices is served by the Connected Device Configuration (CDC). To ensure upward
compatibility between configurations, the CDC shall be a superset of the CLDC. This is used with
the C virtual machine (CVM) and is used for 32-bit architectures requiring more than 2 MB of
memory.
Profiles
The J2ME framework provides the concept of a profile to make it possible to define Java
platforms for specific vertical markets. Profiles can serve two distinct portability requirements:
A profile provides a complete toolkit for implementing applications for a particular kind
of device, such as a pager, set-top box, cell phone, washing machine, or interactive
electronic toy.
A profile may also be created to support a significant, coherent group of applications
that might be hosted on several categories of devices.
Foundation profile contains APIs of J2SE without GUIs. Personal Profile is profile for embedded
devices. Two profiles have been defined for J2ME and are built on CLDC: K Java and Mobile
Information Device Profile (MIDP). These profiles are geared toward smaller devices.
JAR File – Contains all of the classes and resources used by the application
JAD File – Application descriptor, describes how to run the MIDP application
1 Java.lang standard java types and classes for String, Integer, Math, Thread,
Security and Exception
2 Java.io Standard java types and classes for input and output streams
4 Javax.microedition.rms A record management system (RMS) API to retrieve and save data
and limited querying capability
small, with a static memory footprint of the virtual machine core in the range of 40
kilobytes to 80 kilobytes (depending on compilation options and the target platform,)
clean, well-commented, and highly portable,
modular and customizable, as “complete” and “fast” as possible without sacrificing the
other design goals.
The “K” in KVM stands for “kilo.” It was so named because its memory budget is measured in
kilobytes (whereas desktop systems are measured in megabytes). KVM is suitable for 16/32-bit
RISC/CISC microprocessors with a total memory budget of no more than a few hundred
kilobytes (potentially less than 128 kilobytes). This typically applies to digital cellular phones,
pagers, personal organizers, and small retail payment terminals.