Alert SMSC

     Alert SMC is often referred as Alert SC. Whenever SMSC unable to deliver a SMS to MS then it will keep try to send that to the corresponding MS till the expiry time of the SMS. (Expiry time is defined by the operator).

Here some cases..

o   Alert SMC-MS Reachable

o   Alert SMC-Memory Available

o   Alert SMC-Short Message Delivery Successful

Note: third case is not a failure case

Alert SMC-MS Reachable signaling flow:

If the MS is not-reachable when the SMC tried to send SMS that corresponding SMS will be resent to the customer once the customer gets coverage i.e customer back to reachable state. 

Once the customer back to reachable state, HLR of the corresponding operator will intimate to the respective SMC. Here the flow for that.

1.            The MS/UE makes or receives a call or performs a location update.

2.            The MSC server sends a Process_Access_Request message to the VLR when the MS/UE makes or receives a call. Or the MSC server sends an Update_Location_Area to the VLR when the MS/UE updates the location area.

3.            The VLR checks the subscriber data. If the VLR detects that the MNRF of the subscriber is set to Mobile Subscriber Reachable, the VLR removes the MNRF and sends a Ready_For_SM message to the HLR. The VLR directly sends an Update_Location request to the HLR in the case of a location update flow.

4.            If the HLR receives a Ready_For_SM message, it checks the dynamic data of the subscriber. If the MNRF is set, the HLR removes the MNRF and sends an Alert_Service_Centre message to the SMC and a Ready_for_SM_Ack message to the VLR. If the HLR receives an Update_Location request and the MNRF in the dynamic data of the subscriber is set, the HLR removes the MNRF, sends an Alert_Service_Centre message to the SMC, and continues the location update flow.

5.            The SMC returns an Alert_Service_Centre_Ack message to the HLR and attempts to resend the short message

Alert SMC-MS Memory Available signaling flow

If the Memory Capacity of the MS full i.e inbox is full,  when the SMC tried to send SMS that corresponding SMS will be resent to the customer once the customer gets available space in inbox.

Once the customer gets available space in inbox, HLR of the corresponding operator will intimate to the respective SMC. Here the flow for that.

1.            The MS/UE sends an SM Memory Capacity Available message to the MSC server over the A/Iu interface.

2.            The MSC server sends a READY_FOR_SM message to the HLR.

3.            The HLR checks the dynamic subscriber data. If the MCEF of the subscriber is set, the HLR removes it and then sends an Alert_Service_Centre message to the MSC server and a READY_FOR_SM_ACK message to the VLR.

4.            The MSC server sends an SM Memory Capacity Available message to the MS/UE.

5.            On receiving the Alert_Service_Centre message, the SMC sends an Alert_Service_Centre_Ack message to the HLR and tries to resend the short message.

Signaling flow for alert SMC-Short Message Delivery Successful

If the SMS is successfully delivered to a MS that will also be informed to the SMC and here the flow for that and this will be sent to the originator as SMS delivery report.

1.            The GMSC server sends a REPORT_SM_DELIVERY_STATUS message to the HLR.

2.            The HLR returns a REPORT_SM_DELIVERY_STATUS_ACK message to the GMSC server.

3.            The HLR sends an Alert_Service_Centre message to the SMC.

4.            The SMC returns an Alert_Service_Centre_Ack message to the HLR.

Basic SMS Flow

                

The below figure is the representation on 3G/UMTS architecture

3G/UMTS

  

Basic SMS Flow

The basic SMS flow consists of the following:

• ·         Short Message Mobile Originated (SMMO)
• ·         Short Message Mobile Terminated (SMMT)

·         

SMMO signaling flow: 

Mobile Originated SMS

1.       The MS/UE sends a short message to the MSC server over the A/Iu interface.

2.       On receiving the SMS request over the A/Iu interface, the MSC server sends a SEND_INFO_FOR_MO_SMS message to the VLR based on the MSISDN of the originating MS/UE.

3.       The VLR checks the subscription information and whether the MSC server supports the SMS, and then returns a SEND_INFO_FOR_MO_SMS_ACK message to the MSC server.

4.       The MSC server analyzes the SEND_INFO_FOR_MO_SMS_ACK message. If the MSC server does not support the SMMO service, or the MS/UE has subscribed to the outgoing call barring service, the MSC server directly sends a Short Message Error (RP_ERROR) message to the MS/UE. Otherwise, the MSC server obtains the address of the SMC from the short message and transparently transmits an MO_FORWARD_SHORT_MESSAGE message to the SMC.

5.       On receiving the MO_FORWARD_SHORT_MESSAGE request, the SMC checks whether the data is valid. If the data is valid, the SMC returns an MO_FORWARD_SHORT_MESSAGE_ACK message to the MSC server.

6.       The MSC server sends a Short Message Acknowledgement message to the MS/UE.

SMMT signaling flow

Mobile Terminated SMS

1.            On receiving a short message, the SMC obtains the called number from the short message, and then sends a SEND_ROUTING_INFO_FOR_SM message carrying the called number to request the HLR for the routing information.

2.            The HLR returns a SEND_ROUTING_INFO_FOR_SM_ACK message to the SMC.

3.            Based on the MSC server number, the SMC sends an MT_FORWARD_SHORT_MESSAGE to the MSC server.

4.            The MSC server requests the VLR to check the data of the SMMT subscriber.

5.            The VLR checks the subscription data and mobility management status, and performs one of the following operations based on the actual conditions:

·         If the subscriber cannot be paged because the SMMT service is not supported, the MS/UE is powered off, the MNRF is set, or the roaming is not allowed, the MSC server returns a failure response to the SMC.

·         If the location area of the MS/UE is known, the MSC server starts paging the MS/UE in the specific location area.

·         If the location area of the MS/UE is unknown, the MSC server starts paging the MS/UE in the coverage area of the MSC server.

6.            The MSC server pages the MS/UE.

7.            The MS/UE returns a paging response to the MSC server.

8.            The MSC server sends a PROCESS_ACCESS_REQUEST_ACK or SEARCH_FOR_MOBILE_SUBSCRIBER_ACK message, requesting that the VLR process the access request from the MS/UE.

9.            The VLR returns a SEND_INFO_FOR_MT_SMS_ACK to the MSC server.

10.          The MSC server sends the short message to the MS/UE.

11.          The MS/UE returns a Short Message Acknowledgement message to the MSC server.

12.          The MSC server sends an MT_FORWARD_SHORT_MESSAGE_ACK message to the SMC.

Diameter Protocol

                 Diameter is a planned replacement of RADIUS. It is an AAA protocol for applications such as network access and IP mobility. Listed below are a few points that you need to know about Diameter:

• It is intended to work in both local and roaming AAA situations.
• It uses TCP or SCTP and not UDP.
• It uses transport level security (IPSEC or TLS).
• It has 32 bit identifier instead of 8 bit.
• It supports application layer acknowledgement, define failover.
• It offers better roaming support.
• It uses AVPs.
• Diameter allows to define new commands and attributes. It is easy to extend.

Authentication

• Refers to confirmation that a user who is requesting a service is a valid user.
• Accomplished via the presentation of an identity and credentials.
• Examples of credentials include passwords, one-time tokens, digital certificates, and phone numbers (calling/called).

Authorization

• Refers to the granting of specific types of service (including "no service") to the users based on their authentication.
• May be based on restrictions, for example, time-of-day restrictions, or physical location restrictions, or restrictions against multiple logins by the same user.
• Examples of services include, IP address filtering, address assignment, route assignment, encryption, QoS/differential services, bandwidth control/traffic management, etc.

Accounting

• Refers to the tracking of the consumption of network resources by users.
• Typical information that is gathered in accounting include the identity of the user, the nature of the service delivered, when the service began, and when it ended.
• May be used for management, planning, billing, etc.
• AAA server provides all the above services to its clients.

  
Diameter nodes and agents
        Diameter is designed as a Peer-To-Peer architecture, and every host who implements the Diameter protocol can act as either a client or a server depending on network deployment. So the term Diameter node is used to refer to a Diameter client, a Diameter server, or a Diameter agent.

         The Diameter node that receives the user connection request will act as the Diameter client. In most cases, a Diameter client will be a Network Access Server. After collecting user credentials, such as username and password, it will send an access request message to one Diameter node serving the request. For simplicity, we assume it is the Diameter server. The Diameter server authenticates the user based on the information provided. If the authentication process succeeds, the user's access privileges are included in the response message and sent back to the corresponding Diameter client. Otherwise, an access reject message is sent.

Relay Agent
      Relay Agent is used to forward a message to the appropriate destination, depending on the information contained in the message. The Relay Agent is advantageous because it can aggregate requests from different realms (or regions) to a specific realm, which eliminates the burdensome configurations of network access servers for every Diameter server change.

Proxy Agent
A Proxy Agent can also be used to forward messages, but unlike a Relay Agent, a Proxy Agent can modify the message content and, therefore, provide value-added services, enforce rules on different messages, or perform administrative tasks for a specific realm. Below Figure shows how a Proxy Agent is used to forward a message to another domain. If the Proxy Agent will not modify the content of an original request, a Relay Agent in this scenario would be sufficient.

Proxy Agent

Redirect Agent
A Redirect Agent acts as a centralized configuration repository for other Diameter nodes. When it receives a message, it checks its routing table, and returns a response message along with redirection information to its original sender. This would be very useful for other Diameter nodes because they won't need to keep a list routing entries locally and can look up a Redirect Agent when needed. Figure 3 illustrates how a Redirect Agent works. The scenario in Figure 3 below is basically identical to the one in Figure 2, but this time the Proxy Agent is not aware of the address of the contacting Diameter node within example.com. Therefore, it looks up the information in the Redirect Agent of its own realm to get the address.

Redirect Agent

.
Translation Agent
In addition to these agents, there is a special agent called Translation Agent. The responsibility of this agent, as you might have guessed, is to convert a message from one AAA protocol to another. The Translation Agent is helpful for a company or a service provider to integrate the user database of two application domains, while keeping their original AAA protocols. Another situation is that a company wants to migrate to Diameter protocol, but the migration consists of many phases. The Translation Agent could provide the backward capability for a smooth migration. Figure 4 shows how one agent translates the RADIUS protocol into the Diameter protocol, but, of course, other kinds of protocol translation (for example, Diameter to RADIUS, Diameter to TACACS+) are also possible.

Translation Agent

Diameter Message
      A Diameter message consists of a fixed-length 20-octet header followed by a variable number of AVPs (Attributed Value Pair). The format of a Diameter message is shown on the figure.

                                        0                                  7                                           31

Version	Message Length
Command Flag	Command code
Application ID
Hop-By-Hop Identifier
End-to-End Identifier
AVPs

                                                                 Diameter message format                                                                         

 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 orredirected 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.

                                   0            1            2               3              4               5              6           7 

R

P

E

T

r

r

r

r

                                                                         Command Flag

 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.



Application-ID
 Application-ID is four octets and is used to identify to which application the message is applicable for.  The application can be an authentication application, an accounting application or a vendor specific application.

The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message.

Application	Application
Diameter Common Messages	0
NASREQ	1
Diameter Base Accounting, Rf , Gz	3
Diameter Credit Control, Ro, Gy	4
Relay	0xFFFFFFFF
Cx/Dx Interface Application	16777216
Rx Interface Application	16777236
Sh/Dh Interface Application	16777217
Re Interface Application	16777218
S6a/S6d Interface Application	16777251
S13/S13 ’ Interface Application	16777252
S9 Interface Application	16777267
Gx Interface Application	16777238
Sy Interface Application	16777302
SWx Interface Application	16777265

 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-by-Hop 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 Origin Host 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 request. What follows the DIAMETER command header is a set of AVPs (Attribute Value Pair)


Command Codes
   Each command Request/Answer pair is assigned a command code, and the   sub-type (i.e., request or answer) is identified via the 'R' bit in    the Command Flags field of the Diameter header.
   Every Diameter message MUST contain a command code in its header's Command-Code field, which is used to determine the action that is to be taken for a particular message. The following Command Codes are defined in the Diameter base protocol:

Diameter Base protocol messages:

Command Name	Abbreviation Command	Code
I. Diameter Connection Management
Capabilities-Exchange-Request	CER	275
Capabilities-Exchange-Answer	CEA	275
Device-Watchdog-Request	DWR	280
Device-Watchdog-Answer	DWA	280
Disconnect-Peer-Request	DPR	282
Disconnect-Peer-Answer	DPA	282
II. Generic Session Operations
Abort-Session-Request	ASR	274
Abort-Session-Answer	ASA	274
Re-Auth-Request	RAR	258
Re-Auth-Answer	RAA	258
Session-Termination-Request	STR	275
Session-Termination-Answer	STA	275
III.Offline Charging
Accounting-Request	ACR	271
Accounting-Answer	ACA	271

 Diameter messages, like RADIUS messages, transport a collection of Attribute-Value Pairs (AVPs). These AVPs carry the detail of AAA as well as routing, security, and capability information between two Diameter nodes. An AVP is a container of data. Each AVP contains an AVP Code, Flags, anAVP Length, an optional Vendor-ID and Data.


    0                                       7                                    31

AVP Codes
Flag	AVP Length
Vendor-ID (optional)
Data

                                    AVP Header Format

AVP Code: The AVP code identifies the type of information (attribute) included in the attribute data field of the AVP. AVP code values are standardized by IETF for the AVPs of the base protocol. New applications should try using the existing AVPs to the extent possible. Diameter saves AVP codes 0-255 for backward compatibility with attributes defined by RADIUS. New applications can define additional AVPs if necessary.


 AVP Flags:
                                               
                              0                 1              2              3             4                5            6             7  

V

M

P

r

r

r

r

r

                                                                                   AVP Flag Format
 The “V” bit, known as the Vendor-Specific bit, indicates whether the optional VendorID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space. If set to 0, it means absence of a Vendor-ID field, which indicates a standard AVP specified by IETF.
  The “M” bit known as Mandatory bit, indicates if the AVP is mandatory (M bit set to 1) or optional (M bit set to 0). If the sender indicates that support for the AVP is mandatory and the receiver does not understand the AVP, the Diameter request is rejected; If the AVP is optional and not understood by the destination, it may be ignored.
 The “P” bit known as Protected bit. The P bit indicates the need for encryption for end-to-end security. Diameter base protocol specifies which AVPs must be protected by end-to-end security measures (encryption) if the message is to pass through a Diameter agent.

                          
                                                                                           

AVP Format

         

Error handling
      Errors in the Diameter fall into two categories: protocol errors and application errors. Protocol errors refer to something being wrong with the underlying protocol used to carry Diameter messages, perhaps incorrect routing information or temporary network failure.
        
   Applications errors, on the other hand, result from the failure of the Diameter protocol itself, and there are plenty of sources that will cause application errors. For example, when a mandatory AVP is missing in a particular Diameter command, a DIAMETER_MISSING_AVP error code is returned. Every response message in Diameter will carry a Result-Code AVP, and the receiver of a response message can check this AVP to see if the previous message was successfully processed.

  The Diameter protocol shares the same semantics of error code definition as the HTTP protocol. The return status of messages can be easily identified by checking the first digit of the return code:

1xxx: means the request can't be satisfied and additional information is required for the service to be granted.

 2xxx: means the request was processed successfully.

3xxx: means there was a protocol error when transmitting a Diameter message. Generally, a Diameter proxy should try to fix this problem by either routing the message to another Diameter server, or by keeping the message in a local cache and sending it again later.

4xxx: means the requested message cannot be satisfied at the moment, but it might work in the future. An example is a server that temporarily lacks physical storage space to handle any incoming requests.

5xxx: means there was an application error when the server was processing the request message. The sender should not try to send the same message again. Instead, the sender will have to determine the cause of the application error by checking the error code, and then fix the problem.