APPLICATION LAYER
1.
WAP Model
2.
Mobile Location based services
3.
WAP Gateway
4.
WAP protocols
5.
WAP user agent profile
6.
caching mode
7.
wireless bearers for WAP
8.
WML
WMLScripts
9.
WTA- iMode-,SyncML
Pre
requisite discussion:
The growth of the internet, internet
applications, and mobile communication led to many early proprietary solutions
providing internet services for mobile, wireless devices. Some of the problems
these partial solutions face were discussed in section
1.WAP Model
Concept:
Figure below 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. This comparison is often cited by the WAP Forum and it helps to understand
the architecture (WAP Forum, 2000a). This comparison can be misleading as not
all components and protocols shown at the same layer are comparable. For
consistency reasons with the existing specification, the following stays with
the model as shown in Figure below 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. No special
interface has been specified between the bearer service and the next higher
layer, the transport layer with its wireless
datagram protocol (WDP)
and the additional wireless control message protocol (WCMP), because the adaptation of
these protocols are bearer-specific
(WAP Forum, 2000u). The transport layer offers a bearer independent, consistent
datagram-oriented service to the higher layers of the WAP architecture.
Communication is done transparently over one of the available bearer services.
The transport layer service access point (T-SAP) is the common interface to be used
by higher layers independent of the
underlying network. 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 the transport layer security (TLS,
formerly SSL, secure sockets layer) already
known from the www. 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. The WAP transaction layer with its wireless
transaction protocol (WTP) offers a lightweight transaction service at the transaction SAP (TR-SAP). This service
efficiently provides reliable or unreliable requests and asynchronous
transactions. Tightly coupled to this layer is the next higher layer, if used
for connection-oriented service. 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. Finally the application layer with the wireless
application environment (WAE) offers a framework for the integration of
different scripting languages,
special markup languages, interfaces to telephony applications, and many
content formats adapted to the special requirements of small, handheld,
wireless devices. Figure 10.9 not only shows the overall WAP architecture, but
also its relation to the traditional internet architecture for www
applications. The WAP transport layer together with the bearers can be
(roughly) compared to the services offered by TCP or UDP over IP and different
media in the internet. If a bearer in the WAP architecture already offers IP
services (e.g., GPRS, CDPD) then UDP is used as WDP. The TLS/SSL layer of the
internet has also been adopted for the WAP architecture with some changes
required for optimization. The functionality of the session and transaction
layer can roughly be compared with the role of HTTP in the web architecture.
However, HTTP does not offer all the additional mechanisms needed for efficient
wireless, mobile access (e.g., session migration, suspend/resume). Finally, the
application layer offers similar features as HTML and Java. Again, special
formats and features optimized for the wireless scenario have been defined and
telephony access has been added. WAP does not always force all applications to
use the whole protocol architecture. Applications can use only a part of the
architecture. For example, this means that, 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 (see
Figure 10.10). 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.
Significance:
∑ interoperable,
i.e., allowing terminals and
software from different vendors to communicate
with networks from different providers;
∑ scaleable,
i.e., protocols and services should
scale with customer needs and number of customers;
∑ efficient,
i.e., provision of QoS suited to the
characteristics of the wireless and mobile
networks;
∑ reliable,
i.e., provision of a consistent and
predictable platform for deploying services; and
∑ secure,
i.e., preservation of the integrity
of user data, protection of devices and services from security problems.
2.
Mobile Location based
services
Concept:
The wireless datagram protocol (WDP) operates on top of many different
bearer services capable of carrying data. At the T-SAP WDP offers a consistent
datagram transport service independent of the underlying bearer (WAP Forum,
2000b). To offer this consistent service, the adaptation needed in the
transport layer can differ depending on the services of the bearer. The closer
the bearer service is to IP, the smaller the adaptation can be. If the bearer
already offers IP services, UDP (Postel, 1980) is used as WDP. WDP offers more
or less the same services as UDP. 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.
If a higher layer requests a service
the WDP cannot fulfill, this error is indicated with the T-DError.ind service primitive as shown in. 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 (e.g. the destination is unreachable, no application
is listening to the specified destination port etc.), the wireless control message protocol (WCMP) provides error handling
mechanisms for WDP (WAP Forum, 2000r) and should therefore be implemented. WCMP
contains control messages that resemble the internet control message protocol
(ICMP (Postel, 1981b) for IPv4, (Conta, 1998) for IPv6) messages and can also
be used for diagnostic and informational purposes. WCMP can be used by WDP
nodes and gateways to report errors. However, WCMP error messages must not be
sent as response to other WCMP error messages. In IP-based networks, ICMP will
be used as WCMP (e.g., CDPD, GPRS). Typical WCMP messages are destination unreachable (route, port,
address unreachable), parameter problem (errors
in the packet header), message too big,
reassembly failure, or echo
request/reply. An
additional WDP management entity supports WDP and provides information about changes in the environment, which may influence the
correct operation of WDP. Important information is the current configuration of
the device, currently available bearer services, processing and memory
resources etc. Design and implementation of this management component is
considered vendor-specific and is outside the scope of WAP. If the bearer
already offers IP transmission, WDP (i.e., UDP in this case) relies on the
segmentation (called fragmentation in the IP context) and reassembly
capabilities of the IP layer as specified in (Postel, 1981a). Otherwise, WDP
has to include these capabilities, which is, e.g., necessary for the GSM SMS
Significance:
Makes the Mobile systems faster.
The WAP is applied in almost all the Base
Station infrastructures.
3. WAP Gateway
Conept:
If requested by an application, a security
service, the wireless transport layer security (WTLS), can be integrated into the WAP architecture
on top of WDP as specified in (WAP Forum, 2000c). 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. New compared to, e.g. GSM, is the security relation between
two peers and not only between the mobile device and the base station (see
chapter 4). WTLS took over many features and mechanisms from TLS (formerly SSL,
secure sockets layer (Dierks, 1999)), 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: illustrates the sequence of service primitives needed for a so-called
full handshake (several optimizations
are possible). The originator and the peer of the secure session can both
interrupt session establishment any time, e.g., if the parameters proposed are
not acceptable. The first step is to initiate the session with the SEC-Create primitive. Parameters are source
address (SA), source port (SP) of the originator, destination address
(DA),
destination port (DP) of
the peer. The originator proposes a key
exchange suite (KES)
(e.g., RSA (Rivest, 1978), DH (Diffie, 1976),
ECC (Certicom, 2002)), a cipher suite
(CS) (e.g., DES, IDEA (Schneier, 1996), and a compression method (CM) (currently not further specified). 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 requests a client certificate (CC) from the
originator. The first step of the secure session creation, the negotiation of
the security parameters and suites, is indicated on the originator s side, followed by the request for a
certificate. The originator answers with its certificate and issues a SEC-Commit.req primitive. This
primitive indicates that the handshake is com pleted for the originator s side and that the originator now wants to
switch into the newly negotiated connection state. The certificate is delivered
to the peer side and the SEC-Commit is indicated. The WTLS layer of the peer
sends back a confirmation to the originator. This concludes the full handshake
for secure session setup. After setting up a secure connection between two
peers, user data can be exchanged. This is done using the simple SEC-Unitdata primitive as shown in the
figure below. SEC-Unitdata has exactly the same function as T-DUnitdata 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. The higher layers
simply use SEC-Unitdata instead of T-DUnitdata. The parameters are the same
here: source address (SA), source port
(SP), destination address (DA),
destination port (DP), and user data
(UD). This section will not
discuss the security-related features of WTLS or the pros and cons of different
encryption algorithms. The reader is referred to the specification (WAP Forum,
2000c) and excellent cryptography literature e.g., (Schneier, 1996), (Kaufman,
1995). Although WTLS allows for different encryption mechanisms with different
key lengths, it is quite clear that due to computing power on the handheld
devices the encryption provided cannot be very strong. If applications require
stronger security, it is up to an application or a user to apply stronger
encryption on top of the whole protocol stack and use WTLS as a basic security
level only. Many programs are available for this purpose. It is important to
note that the security association in WTLS exists between the mobile
WAP-enabled device and a WAP server or WAP gateway only. If an application
accesses another server via the gateway, additional mechanisms are needed for
end-to-end security. If for example a user accesses his or her bank account
using WAP, the WTLS security association typically ends at the WAP gateway
inside the network operator s domain.
The bank and user will want to apply additional security mechanisms in this
scenario. Future work in the WTLS layer comprises consistent support for
application level security (e.g. digital signatures) and different
implementation classes with different capabilities to select from.
4. WAP protocols Conept:
The wireless
transaction protocol (WTP) is on top of either WDP or, if security is
required, WTLS (WAP Forum, 2000d). 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. In this context, a transaction is defined as a
request with its response, e.g. for a web page. WTP offers many features to the
higher layers. The basis is formed from three classes of transaction service as explained in the following paragraphs.
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. No
WTP-class requires any connection set-up or tear-down phase. This avoids
unnecessary overhead on the communication link. 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). To be consistent
with the specification, in the following the term initiator is used for a WTP entity initiating a
transaction (aka client), and the term responder for the WTP entity responding to a transaction
(aka server). 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. The use of the service primitives, the PDUs,
and the associated parameters with the classes of transaction service will be explained in
the following sections. A special feature of WTP is its ability to provide a user
acknowledgement or,
alternatively, an automatic acknowledgement by the WTP entity. If user acknowledgement is
required, a WTP user has to confirm every message received by a WTP entity. A user
acknowledgement provides a stronger version of a confirmed service because it
guarantees that the response comes from the user of the WTP and not the WTP
entity itself.
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 in Figure 10.14. Parameters
are the source address (SA), source port (SP), destination address (DA), destination port (DP) as already explained in section 10.3.2.
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. In
this class, the responder does not acknowledge the message and the initiator
does not perform any retransmission. Although this resembles a simple datagram
service, it is recommended to use WDP if only a datagram service is required.
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 in Figure 10.15. The responder signals the incoming invoke
PDU via the TR-Invoke.ind primitive to the higher layer and acknowledges
automatically without user intervention. The specification also allows the user
on the responder s side to acknowledge,
but this acknowledgement is not required. 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 fig below. 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
Finally, 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. The basic transaction of class 2 without-user acknowledgement. Here, a
user on the initiator s side requests
the service and the WTP entity sends the invoke PDU to the responder. The WTP
entity on the responder s side indicates
the request with theTR-Invoke.ind primitive to a user. The responder now waits
for the processing of the request, the user on the responder s side can finally give the result UD* to the
WTP entity on the responder.
Wireless
session protocol
The wireless session protocol (WSP) has been designed to operate on top of the
datagram service WDP or the transaction service WTP (WAP Forum, 2000e). For
both types, security can be inserted using the WTLS security layer if required.
WSP provides a shared state between a client and a server to optimize content
transfer. HTTP, a protocol WSP tries to replace within the wireless domain, is
stateless, which already causes many problems in fixed networks. Many web
content providers therefore use cookies to store some state on a client
machine, which is not an elegant solution. State is needed in web browsing, for
example, to resume browsing in exactly the same context in which browsing has
been suspended. This is an important feature for clients and servers. Client
users can continue to work where they left the browser or when the network was
interrupted, or users can get their customized environment every time they
start the browser. Content providers can customize their pages to clients needs and do not have to retransmit the same
pages over and over again. WSP offers the following general features needed for
content exchange between cooperating clients and servers:
Significance:
● 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. Assume a mobile device is being switched off it would be useful
for a user to be able to continue operation at exactly the point where the
device was switched off. Session lifetime is independent of transport
connection lifetime or continuous operation of a bearer network.
●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.
5. WAP user agent profile
Conept:
The schema for WAP User Agent Profiles consists
of description blocks for the following key components:
HardwarePlatform:
A collection of properties that adequately
describe the hardware characteristics of the terminal device. This includes, the type of
device, model number, display size, input and output methods, etc.
SoftwarePlatform:
A collection of attributes associated with the
operating environment of the device. Attributes provide information on the operating system software,
video and audio encoders supported by the device, and user s preference on language .
BrowserUA:
A set of attributes to describe the HTML
browser application NetworkCharacteristics: Information about the network-related
infrastructure and environment such as bearer information. These attributes can influence the
resulting content, due to the variation in capabilities and characteristics of
various network infrastructures in terms of bandwidth and device accessibility.
WapCharacteristics:
A set of attributes pertaining to WAP
capabilities supported on the device. This includes details on the capabilities and characteristics related
to the WML Browser, WTA [WTA], etc.
Significance:
Faster when compared to all other user agent
profiles.
6. Caching mode Conept:
Caching can reduce the bandwidth requirement in
a mobile computing environment. However, due to battery power limitations, a
wireless mobile computer may often be forced to operate in a doze (or even
totally disconnected) mode. As a result, the mobile computer may miss some
cache invalidation reports broadcast by a server, forcing it to discard the
entire cache contents after waking up. In this paper, we present an
energy-efficient cache invalidation method, called GCORE (Grouping with COld update-set
REtention), that allows a mobile computer to operate in a disconnected mode to
save the battery while still retaining most of the caching benefits after a
reconnection. We present an efficient implementation of GCORE and conduct
simulations to evaluate its caching effectiveness. The results show that GCORE
can substantially improve mobile caching
by reducing the communication bandwidth (or energy consumption) for query
processing
While a WSP session is established
(whether active or suspended), the WAP gateway caches all Profile and Profile-
Diff headers associated with that session. A third party host may issue a
request for this CPI to, for instance, generate content that wil subsequently
be pushed to the client device. The request is initiated from the third-party
host and delivered to a Push Protocol Gateway (PPG). This specification defines
neither a protocol for issuing this request nor a means for addressing the
requested information. However, it is expected that such requests will typically
be made to the WAP gateway using HTTP, as suggested by [WAP-PAP]. Upon
receiving the profile request, the gateway accesses the cached Profile and
Profile-Diff headers and resolves them to form a complete CPI profile. It
responds to the CPI request with the resolved profile (a CC/PP document) using
a MIME type of text/xml.
It is important to note that the WAP
gateway has incomplete information about the current CPI. In particular, the
gateway is not aware of any request-specific profile information that the
client would have provided to the requesting third-party server. Moreover, the
WAP gateway cannot incorporate attribute information from Profile-Diff headers
that would have been added by intermediate proxies through which the request
would have passed had it originated at the client device. Finally, if the WSP
session is currently suspended, then the gateway may be caching out-of-date
profile information.
7. Wireless bearers for WAP
Conept:
The above one defines properties for
conformant User Agent Profiles, which are structured according to the CC/PP
note [CC/PP], and correspondingly use RDF XML serialization syntax. This
section defines a set of single-byte tokens corresponding to the attribute
names and values of the RDF serialization syntax. These tokens are distributed
among three code pages. Code page zero (0) defines tokens for RDF serialization
attributes. Code page one (1) defines tokens for properties in the core profile
schema. Code page two (2) defines tokens for properties in the Browser useragent
component of the schema. User agents or applications other than the browser may
define additional attribute code pages for their own properties. Each user
agent or application that wants to define properties for use in the user agent
profile MUST first define a component to hold its properties. The name of the
component MUST be globally unique. Each such user agent component is considered
to have a unique namespace, so that, for example, the property BackgroundColor
for User Agent A is a property distinct from the property BackgroundColor for
User Agent B. See Section 7for more information. In addition, each user agent
or application SHOULD define a series of token table code pages containing the
properties from its component. If it chooses to define code pages, then it
SHOULD define at least two: one in the "Tag" space and one in the
"Attribute" space. The property names SHOULD be inserted into each
page. Any wellknown values for the properties should be inserted into the
"Attribute" page. Additional pages may be required if the component
contains a large number of properties. A default user agent has been defined as
part of the schema: the browser.
Significance:
These wireless bearers provides a
major advantage of making a wireless telecommunication using the WAP
8. WML WMLScripts
Conept:
WML (Wireless Markup Language),
formerly called HDML (Handheld Devices Markup Languages), is a language that
allows the text portions of Web pages to be presented on cellular telephones
and personal digital assistants (PDAs) via wireless access. WML is part of the
Wireless Application Protocol (WAP) that is being proposed by several vendors
to standards bodies. The Wireless Application Protocol works on top of standard
data link protocols, such as Global System for Mobile communication,
code-division multiple access, and Time Division Multiple Access, and provides
a complete set of network communication programs comparable to and supportive
of the Internet set of protocols.
WML is an open language offered
royalty-free. Specifications are available at Phone.com's Web site. According
to Phone.com, any programmer with working knowledge of HTML, common gateway
interface, and Structured Query Language should be able to write a presentation
layer using WML. A filter program can be written or may be available from a
vendor that will translate HTML pages into WML pages.
Significance:
This WML is much more preferred than
the HTML mainly because of its User interface
9. WTA- iMode-,SyncM
Conept:
The most common wireless technologies
use radio. With radio waves distances can be short, such as a few meters for
television or as far as thousands or even millions of kilometers for deep-space
radio communications. It encompasses various types of fixed, mobile, and
portable applications, including two-way radios, cellular telephones, personal
digital assistants (PDAs), and wireless networking. Other examples of
applications of radio wireless technology include GPS units, garage door
openers, wireless computer mice, keyboards and headsets, headphones, radio
receivers, satellite television, broadcast television and cordless telephones.
Somewhat less common methods of
achieving wireless communications include the use of other electromagnetic
wireless technologies, such as light, magnetic, or electric fields or the use
of sound.
Light, colors, AM and FM radio, and
electronic devices make use of the electromagnetic spectrum. The frequencies of
the radio spectrum that are available for use for communication are treated as
a public resource and are regulated by national organizations such as the
Federal Communications Commission in the USA, or Ofcom in the United Kingdom.
This determines which frequency ranges can be used for what purpose and by
whom. In the absence of such control or alternative arrangements such as a
privatized electromagnetic spectrum, chaos might result if, for example,
airlines didn't have specific frequencies to work under and an amateur radio
operator were interfering with the pilot's ability to land an aircraft. Wireless
communication spans the spectrum from 9 kHz to 300 GHz.
Applications:
Wi-Fi is a wireless local area network that
enables portable computing devices to connect easily to the Internet.
Standardized as IEEE 802.11 a,b,g,n, Wi-Fi approaches speeds of some types of
wired Ethernet. Wi-Fi has become the de facto standard for access in private
homes, within offices, and at public hotspots.[19] Some businesses charge
customers a monthly fee for service, while others have begun offering it for
free in an effort to increase the sales of their goods.
Cellular data service offers coverage within a
range of 10-15 miles from the nearest cell site. Speeds have increased as
technologies have evolved, from earlier technologies such as GSM, CDMA and
GPRS, to 3G networks such as W-CDMA, EDGE or CDMA2000.
Mobile Satellite Communications may be used
where other wireless connections are unavailable, such as in largely rural
areasor remote locations. Satellite communications are especially important for
transportation, aviation, maritime and military use
Wireless Sensor Networks are responsible for
sensing noise, interference, and activity in data collection networks. This
allows us to detect relevant quantities, monitor and collect data, formulate
meaningful user displays, and to perform decision-making functions.
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.