Monday, September 28, 2015

Evolution of Wireless Communication Technologies


0 G
1946
Mobile radio telephone
These systems preceded modern cellular mobile telephony technology.
Technologies included the Push to Talk (PTT or manual), Mobile Telephone System (MTS), Improved Mobile Telephone Service (IMTS), and Advanced Mobile Telephone System (AMTS) systems.


1G
1981
Analog
Network used analog radio signals.
Fully automated on the carrier's end without requiring any human operator intervention, and used electronics that could be miniaturized enough to fit into smallish packages
AMPS in the US & TACS and NMT in Europe

Problems
  • not very scalable
  • security was very poor

2G
1991
GSM
IS-95 CDMA/ cdmaOne
Network used digital radio signals.
2G cellular telecom networks were commercially launched on the GSM standard in Finland.

Three primary benefits of 2G networks over their predecessors
  1. Phone conversations were digitally encrypted
  2. Significantly more efficient on the spectrum allowing for far greater mobile phone penetration levels
  3. Introduced data services for mobile like SMS, MMS.
Supported CSD that allowed you to place a dial-up data call digitally.

Main 2G Standards
  • GSM (TDMA-based)
  • IS-95 aka cdmaOne (CDMA-based)
Limitations
  • Spectrum limitations
  • Low data rates
2.5G
1997
GPRS
Permitted "always-on" data services. No dial-up.
Operators could effectively bill by the kilobyte, rather than by the minute.
Virtually every GSM operator in the world deployed it
Wasn’t fast enough to meet 3G required speeds, hence the term 2.5G.
2.75G
1999
EDGE
Allowed more speed without investing a lot on UMTS hardware upgrades and spectrum.
With an EDGE-compatible phone, you could get speeds over double what you got on GPRS
ITU refer EDGE as an ITU-2000 Narrowband technology
3G
2003
UMTS

Component of IMT-2000 Standard  by ITU
Developed and maintained by the 3GPP
Uses W-CDMA
IS 2000
CDMA 2000


3.5G
2008
HSPA
Improved 3G using W-CDMA protocols.
Amalgamation of two mobile telephony protocols,
  • HSDPA: 14.4Mbps
  • HSUPA: 5.76Mbps
3.75G
2010
HSPA+
DC-HSPA+ HSPA+ Evolution
14Mbps
28Mbps
4G
2011
LTE
Mobile WiMAX
LTE Advanced
IMT-Advanced Standard  by ITU calls for
4G technologies to deliver downlink speeds of 1Gbps when stationary and 100Mbps when mobile, roughly 500-fold and 250-fold improvements over IMT-2000, respectively.
LTE doesn’t meet it, LTE advanced does(only 1 network in the world)
Use OFDMA
Lack a dedicated voice network -- 100 percent of their spectrum is used for data services, voice calls are treated as VoIP.

Diameter for Dummies

Diameter protocol is the successor of the Radius protocol. Somebody thought it’d be interesting to call the feature rich successor  of RADIUS (which of course is an acronym that stands for Remote Authentication Dial-In User Service) as diameter.

Diameter is a AAA protocol for computer networks. (AAA = authentication, authorization, and accounting)

There is a base diameter protocol and protocols that extend the base protocol. The base protocol provides basic mechanisms for reliable transport, message delivery, and error handling.

Diameter Applications

Extended ones are called Diameter Applications. Don’t be deceived by the word application. They are just some more protocols defining new command codes and/or new mandatory AVPs. (More on AVPs later)  For example Diameter Credit-Control Application
is a protocol that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.
Each application relies on the common functionality provided by of the base protocol.

Diameter Mobile IPv4 Application
Diameter Network Access Server Application
Diameter Extensible Authentication Protocol Application
Diameter Credit-Control Application
Diameter Session Initiation Protocol Application

Diameter Message

Diameter is a byte based protocol. Each message has a fixed structure, which consists of two parts: header and payload. There are two types of messages, Requests and Answers. Every answer message carries a Result-Code AVP.

A Diameter message looks like this.


Message Headers

Version
Indicates the Diameter protocol version. This value is always set to 1.
Message Length
Indicates the Diameter message length, including the header fields.
Flags
Composed by eight bits, to provide information regarding the message. T he first four bits in the
flags octet have the following meaning:
Flag
1
0
R
The message is a request
The message is an answer
P
The message is proxiable and may be proxied, relayed or redirected
The message must be processed locally
E
Error message
Regular message
T
Message is potentially being re-transmitted
Message is being sent for the first time

The last four bits are reserved for future use, and should be set to 0.
Command Code
Indicates the command associated with the message.
Command Code in diameter message is used to determine the action that is to be taken for a particular message.

AA-Request
AAR
265
AA-Answer
AAA
265
Credit-Control-Request
CCR
272
Credit-Control-Answer
CCA
272
Application-ID
Identifies the application to which the message is applicable for. The application is an authentication, accounting, or vendor specific application. The application-id in the header must be the same as what is contained in any relevant AVPs in the message.
Hop-by-Hop ID
A unique ID, which is used to match requests and answer. The header field of the answer message must contain the same value present in the corresponding request. This is how answers are routed back to the peer that sent the message.
End-to-End ID
A time-limited unique ID that is used to detect duplicate messages. The ID must be unique for at least four minutes. The answer message originator must ensure that this header contains the same value present in the corresponding request.


AVP
AVPs, Attribute-Value Pairs, are used to send across information in a Diameter message and are included in the message payload. Apart from the standard AVPs that are defined in diameter base protocol and diameter applications, custom AVPs can be defined making diameter easy to extend.



AVP Code
Uniquely identifies the AVP. AVP numbers 1 to 255 are reserved for RADIUS backwards compatibility.
Flags
Flags octets have the following structure: V M P r r r r r.
V:  Vendor Specific
M: Mandatory
P: Protected
The last 5 bits are reserved for future use, and should be set to 0.
AVP Length
Indicates the number of octets in the AVP.
Vendor-ID
An optional octet that identifies the AVP in application space. AVP code and AVP Vendor-ID create a unique identifier for the AVP.


Each AVP has a similar structure: a header, and encoded data and data can be various data types.
Diameter defines data types of;
Integer32
Unsigned32
Integer64
Unsigned64
Float32
Float64
Float128
OctetString
Grouped

A Grouped AVP is an AVP whose data is a sequence of AVPs.

Following derived data formats are also defined.
Enumerated
DiameterIdentity
time
UTF8String
IPFilterRule
QosFilterRule

Every Diameter message carries the Diameter Identity of the originating Diameter process in the Origin-Host AVP and the realm of the originating Diameter process in the Origin-Realm AVP.

Message Flow
A Diameter node is a host process that implements the Diameter protocol and acts as either a client, an agent, or a server. Two Diameter nodes sharing a direct TCP or SCTP transport connection are called Diameter peers.

The communication between two diameter peers starts with the establishment of a transport connection (TCP or SCTP). The initiator then sends a Capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA).
Diameter security is provided by IPsec or TLS. If TLS (Transport Layer Security) is used TLS negotiation will happen as well.

The connection is then ready for exchanging application messages.

If no messages have been exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other peer must respond with Device-Watchdog-Answer.

Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.