LTA
Long Term Evolution (LTE) is the preferred development path of currently deployed GSM/WCDMA/HSPA networks, and is the increasingly preferred option for the evolution of CDMA networks
• LTE allows networks to offer a higher data throughput to mobile devices, which is required in order to deliver new and advanced mobile broadband services to businesses and consumers
• Based on 3GPP standards, the primary objective of LTE is to provide services with a quality at least equivalent to what an end-user can experience today using fixed broadband access at home. It also aims to reduce operational expenses by means of introducing a flat IP architecture
• Some of the key objectives to LTE involve higher data rates, lower latency,
and an all IP network
DIAMETER message format
A Diameter message consists of a fixed-length 20-octet header followed by a variable
number of AVPs (Attributed Value Pair). T
The Version field indicates the Diameter protocol version and is set to 1 for now.
The Command flags field specifies 4 flags for now:
The command code value indicates the command associated with the message, such as “credit-control-request ” or “accounting-request”, and so on. Every Diameter message must contain a command code so that the receiver can determine what action it needs to take for each message. The command code is the same of the request and its corresponding answer.
number of AVPs (Attributed Value Pair). T
The Version field indicates the Diameter protocol version and is set to 1 for now.
The Command flags field specifies 4 flags for now:
- R flag (stands for Request) shows whether the message is a request or a response.
- P flag (stands for Proxiable) shows if the message can be proxied, relayed or redirected or it must be locally processed.
- E flag (stands for Error) to show if the message contains protocol or semantic errors. When a request message generates a protocol error an answer message is sent back with the ‘‘E’’ bit set in the Diameter header, indicating a protocol error.
- T flag to show that a message can potentially be a retransmitted message after a link fail-over or is used to aid removal of duplicate messages.
- r : these flag bits are reserved for future use, and must be set to zero, and ignored by the receiver.
The command code value indicates the command associated with the message, such as “credit-control-request ” or “accounting-request”, and so on. Every Diameter message must contain a command code so that the receiver can determine what action it needs to take for each message. The command code is the same of the request and its corresponding answer.
- Application ID identifies the specific application the message is used for, such as S6a/S6d between MME and HSS, Gx between PCEF and PCR, etc.
- Hop-by-hop identifier field carries an identifier that is used to match request and responses over that hop. The sender of the request must ensure that the identifier is unique over the connection on that hop at any given time. The sender of a response must ensure that the identifier value is the same as that in the corresponding request. . The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-byHop Identifier must be discarded. Hop-by-Hop identifier allows a Diameter response to follow the same route as the corresponding Diameter request.
- End-to-end identifier is an identifier used to detect duplicate messages. The identifier in a response message must match the identifier in the corresponding request message. The identifier must remain locally unique for at least 4 minutes. This identifier and the OriginHost AVP are used together to detect message duplicates. Note duplicate request could cause duplicate responses but the duplications must not affect any states that were created by the original reques
What is diameter protocol? Explain
The RADIUS protocol (Remote Access Dial In User Services) has been widely and successfully deployed to provide authentication, authorization, and accounting (AAA) services for dial-up PPP/IP and Mobile IP access. However, inherent shortcomings of the RADIUS protocol have limited its ability to adapt to the ever-increasing capabilities of routers and network access servers, and the ever-expanding set of desired AAA services.
A number of working groups have specified their requirements for AAA protocols, and these requirements drove the design of the Diameter protocol. The Roaming Operations (ROAMOPS) Working Group of the IETF published a set of requirements for roaming networks.
The NAS Requirements (NASREQ) Working Group of the IETF documented the next generation NAS AAA requirements. The Mobile IP Working Group of the IETF documented AAA requirements that would help Mobile IP scale for Inter-Domain mobility. The Telecommunication Industry Association (TIA) TR-45.6 Adjunct Wireless Packet Data Technology working group documented the CDMA2000 Wireless Data Requirements for AAA. Based on the work of TR-45.6, 3GPP2 has specified a two phased architecture for supporting Wireless IP networking based on IETF protocols;the second phase requiring AAA functionality not supportable in RADIUS.
Diameter was specifically designed to meet the requirements indicated by these various groups.Diameter is currently focused on, and limited to, supporting access to IP networks. The Diameter protocol was designed as an improved version of the RADIUS protocol.
A goal was to maximize compatibility and ease migration from RADIUS to Diameter.For example, a Diameter message, like a RADIUS message, conveys a collection of attribute value pairs. Diameter is defined in terms of a base protocol and a set of applications. This design allows the protocol to be extended to new access technologies. The base protocol provides basic mechanisms for reliable transport, message delivery, and error handling.
DIAMETER ADVANTAGES OVER RADIUS
Better Transport
Diameter runs over a reliable transport, TCP or SCTP.
Lost packets are retransmitted at each hop.
A persistent connection with an application-level heartbeat message (called a
Watchdog message) supports timely failover.
TCP and SCTP adapt to network congestion.
Better Proxying
Hop-by-hop transport failure detection allows failover to occur at the appropriate
place — proxies can locally failover to an alternate next-hop peer.
The proxy automatically does retransmission of pending request messages following
a failover.
An AVP that identifies the ultimate destination allows multiple transactions for a
given session to be routed to the same home server.
Better Session Control
Session management is independent of accounting. Accounting information can be
routed to a different server than authentication/authorization messages. Session
termination is conveyed by a specific Session-Termination message rather than an
Accounting Stop message.
The server may initiate a message to request session termination.
The server may initiate a message to request re-authentication and/or reauthorization
of a user.
Better Security
Hop-by-hop security is provided using IPsec or TLS.
End-to-end security protects the integrity and/or confidentiality of sensitive AVPs
through intermediate proxies.
OVER
Subscribe to:
Posts (Atom)