There are a number of reasons for the success of the TCP/IP protocols over OSI:

1. TCP/IP protocols were specified, and enjoyed extensive use, prior to ISO standardization of alternative protocols. Thus, organizations in the 1980s with an immediate need were faced with the choice of waiting for the always promised, never-delivered complete OSI package, and the up-and-running, plug-and-play TCP/IP suite. Once the obvious choice of TCP/IP was made, the cost and technical risks of migrating from an installed base inhibited OSI acceptance.
2. The TCP/IP protocols were initially developed as a U.S. military research effort funded by the Department of Defense (DOD). Although DOD, like the rest of the U.S. government, was committed to international standards, DOD had immediate operational needs that could not be met during the 1980s and early 1990s by off-the-shelf OSI-based products. Accordingly, DOD mandated the use of TCP/IP protocols for virtually all software purchases. Because DOD is the largest consumer of software products in the world, this policy created an enormous market, encouraging vendors to develop TCP/IP based products.
3. The Internet is built on the foundation of the TCP/IP suite. The dramatic growth of the Internet, and especially the World Wide Web, has cemented the victory of TCP/IP over OSI.

The TCP/IP Approach

The TCP/IP protocol suite recognizes that the task of communications is too complex and too diverse to be accomplished by a single unit. Accordingly, the task is broken up into modules or entities that may communicate with peer entities in another system. On entity within a system provides services to other entities and, in turn, uses the services of other entities. Good software-design practice dictates that these entities be arranged in a modular and hierarchical fashion.

The OSI model is based on this system of communications, but takes it one step further, recognizing that, in many respects, protocols at the same level of the hierarchy have certain features in common. This thinking yields the concept of rows or layers, as well as the attempt to describe in an abstract fashion what features are held in common by the protocols with in a given row.

As an explanatory tool, a layered model has significant value and, indeed, the OSI model is used for precisely that purpose in many books on data communications and telecommunications. The objection sometimes raised by the by the designers of the TCP/IP protocol suite and its protocols is that the OSI model is prescriptive rather than descriptive. It dictates that protocols within a given layer perform certain functions, which may not be always desirable. It is possible to define more than one protocol at a given layer, and the functionality of those protocols may not be the same or even similar. Rather, what is common about a set of protocols at the same layer is that they share the same set of support protocols at the next lower layer.

Furthermore, there is the implication in the OSI model that, because interfaces between layers are well-defined, a new protocol can be substituted for an old one at a given layer with no impact on adjacent layers; this is not always desirable or even possible. For example, a LAN lends itself easily to multicast and broadcast addressing at the link level. If the IEEE 802 link level were inserted below a network protocol entity that did not support multicasting and broadcasting that service would be denied to upper layers of the hierarchy. To get broadcasting, that services would be denied to upper layers of the hierarchy. To get around some of these problems, OSI proponents talk of null layers and sub layers. It sometimes seems that these artifacts save the model at the expense of good protocol design.

In the TCP/IP model, as we shall see, the strict use of all layers is not mandated. For example, there are application-level protocols that operate directly on top of IP.

TCP/IP Protocol Architecture

As we pointed out, there is no official TCP/IP protocol model. However, it is useful to characterize the protocol suite as involving five layers. These layers are:

· Application layer: Provides communication between processes or applications on separate hosts.

· Host-to-host, or transport layer: Provides end-to-end, data-transfer service. This layer may include reliability mechanisms. It hides the details of the underlying network or networks from the application layer.

· Internet layer: Concerned with routing data from source to destination host through one or more networks connected by routers.

· Network layer: Concerned with the logical interface between an end system and sub network.

· Physical layer: Defines characteristics of the transmission medium, signaling rate, and signal-encoding scheme.

• Driven by European telecom manufacturers, operators, and standardization committees

• Very widely used around the world

GSM Features

1.Service portability

• Mobile can be used in any of the participating countries with international roaming and
standardized numbering & dialing (but possibly at different rates!)
• Usable for both wire line services and for mobile service
• Usable when: walking, driving, boating, … (up to 250 km/h)

2. Quality of service and Security

• Quality at least as good a previous analog systems
• Capable of offering encryption

3. Good radio frequency utilization

• High spectrum efficiency
• Co-existence with earlier systems in the same bands

4. Modern network

• Following ITU recommendations – to allow efficient inter- operation with ISDN
networks
• Supporting voice and low rate data.
• Standardized mobility and switching support.
• Standardized interfaces between the sub-systems, to allow a mix-and-match system.

5. System optimized to limit cost of mobiles (and to a lesser extent to limit the cost of the whole system)

• GSM required higher complexity mobiles than earlier analog systems
• Subscriber cost less than or equal to existing analog systems

Incoming Call

1.Incoming call is passed from the fixed network to the GMSC (Gateway Mobile Switching Center).

2.Based on the IMSI(International Mobile Subscriber Identity) numbers of the called party, HLR (Home Location Register) is determined

3.HLR checks for the existence of the called number, then the relevant VLR (Visitor Location Register) is requested to provide a Mobile Station Roaming Number (MSRN).

4.Reply transmitted back to the GMSC.

5.Connection is switched through to the responsible MSC

6.VLR is queried for the location range and reach ability status of the mobile subscriber.

7. If the MS (Mobile Station) is marked reachable, then a radio call is enabled

8. Radio call is executed in all radio zones assigned to the VLR

9. Reply from the MS in its current radio cell

10. When mobile subscriber telephone responds to the page, then complete all necessary security procedures

11. If this is successful, the VLR indicates to the MSC that call can be completed

12. Call can be completed

CDPD does not communicate with the underlying network (but does utilize knowledge of this networks channel assignment algorithms to predict when channels will be available for CDPD’s use).

Mobile Data Base Stations – do channel sniffing to find idle channels. It is essentially an implementation of Mobile*IP.

Motivation for CDPD:

Most traditional cellular systems (such as AMPS) are unsuited for packet data

• Long call setup times – many seconds (vs. CDPD with from under 1 to 4 sec)
• Modem handshaking required – this modem training can take more time than the data
transfer time!
• Analog providers already have AMPS allocation
• Re-use AMPS channels to provide data service.
•Must not interfere with existing analog service (i.e., operator’s bread and butter)
• no new spectrum license needed – but you get to make more money with the
spectrum you already have (IFF you can share the spectrum wisely)

Goals:

•Low speed data: Paging, short message, e-mail, …(achieve 10-12kbps)
• Broadcast and multicast (for example, for fleet management)
• "always on-line" packet data service
• Transparent to existing AMPS service, but shares spectrum with it

CDPD Entities

Mobile End System (M-ES)

• Subscriber unit – interfaces with the radio at 19.2 kbps
• Subscriber Identity Module (SIM) – used to identify subscriber
• Mobile Application Subsystem – actually provides the functionality
(could be a PDA, Laptop, embedded processor, …)

Mobile Data Base Station (MDBS)

• controls the radio: radio channel allocation, channel usage, …
• one modem/transceiver per radio channel pair (up & down link)
• generally co-located with the AMPS base stations (so they can share antenna, site, …)

Mobile Data-Intermediate System (MD-IS)

• Frame relay switch + packet router.
• Buffers packets intended to M-ES it knows about (with TEI assigned).
• Supports user mobility by a mobile location protocol.

Roaming Management

•Each M-ES has a unique Network Equipment Identifier (NEI) which is associated with a
home MD-IS (Mobile Home serving Function (MHF) {a Mobile IP Home Agent}.
•Home MD-IS keeps location directory of the MD-IS currently serving each of its mobiles.
•Each MD-IS keeps a registration directory listing currently visiting mobile (Mobile
Serving Function (MSF)) {a Mobile IP Foreign Agent}.
•When a M-ES moves, the home MD-IS explicitly cancels the registration at the former
MD-IS.
•Packet routing is handles just as in Mobile IP.

CDPD Support

1.CDPD supports both:
• ISO connectionless network protocol
• IP
2. CDPD has explicit provisions for Multicast and enables mobiles to register for a
multicast NEI – this must include a Group Member Identifier (GMID) which is unique
with in the group.

Limitations

•No direct M-ES to M-ES communication
• Radius of a CDPD cell is limited to <10 miles (i.e. < 17km)
• Each M-ES can only send two packets back to back – to avoid hogging the channel

Operation of MBDS & M – ES

MDBS broadcasts a list of available channels. When M-ES finds link quality has dropped below a threshold, it checks the channels from the MDBS’s that it can hear; if there is a better channel it initiates a link transfer – by switching to the new channel and registering with the new MDBS

MD-IS maintains a registration directory

• Contains a list of Temporary Equipment Identifiers (TEI)
• Associated with each TEI is a element inactivity timer (T203)

• Associated with each radio channel stream is a TEI notification timer (T204) – when
this timer goes off MD-IS broadcasts a list of TEI’s with data buffered for them
{mobiles with nothing to send can sleep until the next TEI notification frame}

• When a mobile wakes up and hears there is data for it, it send a Receiver Ready (RR)
frame