Check IMEI (Equipment Status- Whilelisted, Blacklisted, Greylisted ) s13/s13' [MME <--> EIR]

As s6a/s6d is a single interface; here s13/s13' is also a single interface because both uses the single application id 16777252. This interface is used MME/SGSN and EIR; MME/SGSN triggers a message ECR to check the whether a equipment used by subscriber is valid or not. EIR is the database that contains the status pertaining to an equipment. Generally EIR and HSS are merged together as telecom operator merges AuC and HSS. 

How does equipment check take place?
  • Operator shall provision the status of  UE (Mobile phone) to one of the below give values. 
  • In attach procedure MME/SGSN  checks the Terminal Information sent by UE(User equipment) in EIR before giving services to the subscriber who is using that UE if it found that sent information is not in database (EIR)then EIR shall send   ; otherwise EIR shall send the equipment state along with Result-Code avp set to DIAMETER_SUCCESS.
  • After Receiving ECA from EIR MME/SGSN process it. MME/SGSN shall check the status of equipment and then perform the action that is locally configured at MME/SGSN on the a basis of received status.
  • Sometime MME/SGSN shall send the subscriber identity IMSI to EIR in User-Name AVP if MME/SGSN has subscriber identity. This is to inform that currently given subscriber is using this equipment.

Message Flow on s13/s13' interfaces
UE:   User Equipment
EIR:  Equipment Identity Register
HSS:  Home Subscriber Server
AuC:  Authentication Center
MME:  Mobility Management Entity
SGSN: Serving GPRS Support Node

An equipment can be uniquely identified by a string of characters (generally digits) that can be classified in following depending upon the usage/type/software of equipment.
1) IMEI/IMEI-SV :Click on IMEI/IMEI-SV for detailed information. 
2) 3GPP2-MEID :Click on 3GPP2-MEID for detailed information.

 An equipment can have one of the following status and usage of status are self-explanatory.
(0)Whitelist :- An authenticated equipment.
(1)Blacklist :- It is stolen; services need to be terminated.
(2)Greylist :- It is the intermediate state of whitelist and blacklist. Telecom operator can use this state proprietorially like activate tracing for equipment etc. 

Telecom operator sets the status of an equipment; as per the guidance of telecom governing bodies as well as the customers request.

s13/s13' contains single message ECR/ECA as following.

ME-Identity-Check-Request (ECR)
Message Format
<ME-Identity-Check-Request>::=<Diameter Header:324,REQ,PXY,16777252>
< Session-Id >
[ Vendor-Specific-Application-Id ]
        { Auth-Session-State }
{ Origin-Host }
        { Origin-Realm }
        [ Destination-Host ]
{ Destination-Realm }
        { Terminal-Information }
        [ User-Name ]
       *[ AVP ]
       *[ Proxy-Info ]
       *[ Route-Record ]
Terminal Information ::= <AVP header: 1401 10415>
[IMEI]
[3GPP2-MEID]
[Software-Version]

*[AVP]
ME-Identity-Check-Answer (ECA) Command
Message Format
<ME-Identity-Check-Answer>::=<Diameter Header:324,PXY,16777252>
< Session-Id >
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
        [ Experimental-Result ] 
        { Auth-Session-State }
        { Origin-Host }
        { Origin-Realm }
        [ Equipment-Status ]
       *[ AVP ]
       *[ Failed-AVP ]
       *[ Proxy-Info ]
       *[ Route-Record ]

Your Comments /Suggestions and Questions are always welcome,  shall clarify with best of our knowledge. So feel free to put Questions.
14 comments:

RFC-6733 (Diameter Base Protocol)



Here we are explained various aspects of Diameter Base Protocol with examples, Topics are as follow:

1) Introduction to Diameter 
       Improvements of Diameter over RADIUS
2) Diameter Message Structure and Message Flow
       Diameter AVP Structure
3) Diameter Peer Discovery
4) Capability Negotiation
5) DIAMETER Connection Establishment
6) Diameter Agents
7) Diameter Peer Connection and Disconnection
8) Diameter Message Transmission
            Peer Table Explained
       Realm Based Routing Table
       Diameter Message Processing

9)    Message Processing at Redirect Agent
10)Securing Diameter Messages

       IPsec [Obsoleted]
       TLS Transport Layer Security
                 DTLS
2 comments:

DIAMETER Capabilities Update Application

For better understanding kindly go through following topic

DIAMETER Connection Establishment


Why do we need capability update procedure?

This basic question that comes in our mind that why do we need this feature in Diameter Applications. Before this feature; Issue was that if want to update/upgrade any application (Client/Server) in OPEN state (i.e. when DIAMETER connection is established) then there is no provision to tell other NODE (Peer) about updated features, We must bring the application Down (i.e. Bring the application to CLOSE state) and Bring it up again with New features. 

Because CER/CEA (Capabilities-Exchange-Request/Answer) is the only message that is used to tell application Ids supported by an APPLICATION and this message is only exchanged once; when an APPLICATION comes up. We could not exchange CER/CEA on DIAMETER established connection. If any DIAMETER connection established Node (Peer) receives this message shall treat CER/CEA as a notification that other node got restarted. It shall relinquish the already established connection and start a fresh connection. In Practical scenario restarting a system is treated as Service Outage; To Avoid service outage DIAMETER Capabilities update feature is provided.

How does DIAMETER Capabilities Update Application work?

  • It is a procedure to dynamically update capabilities of an Application (Client/Server). Application that is wanted to use this feature MUST advertise Application-Id 10 in CER/CEA (Capabilities-Exchange-Request/Answer)message. Both communicating nodes MUST support Application-Id 10.
  • An application that is going to send Capabilities-Update-Request (CUR) shall send all the Application-Ids currently supported by it (rather than sending only upgraded) on established connection. This message can not modify the security constraint applied on established connection.
  • Receiver of CUR MUST look for intersection of supported Application-Ids received with its own Application-Ids, If there are some common applications then it shall send CUA with Result-Code set to DIAMETER_SUCCESS and shall store the values of Application-Ids else it send Result-Code set to DIAMETER_NO_COMMON_APPLICATION and should terminate transport connection, if there are some on going sessions then it may delay the termination process till completion of sessions.
  • Capabilities-Update-Request/Answer command code id 328 and Message Format is as follow:


       <CUR> ::= < Diameter Header: 328, REQ >
                { Origin-Host }
                { Origin-Realm }
             1* { Host-IP-Address }
                { Vendor-Id }
                { Product-Name }
                [ Origin-State-Id ]
              * [ Supported-Vendor-Id ]
              * [ Auth-Application-Id ]
              * [ Acct-Application-Id ]
              * [ Vendor-Specific-Application-Id ]
                [ Firmware-Revision ]
              * [ AVP ]
       <CUA> ::= < Diameter Header: 328 >
                               { Origin-Host }
                               { Origin-Realm }
                               { Result-Code }
                               [ Error-Message ]
                             * [ AVP ]
  • During the processing of CUR/CUA message Vendor-Id AVP in the Vendor-Specific- Application-Id MUST NOT be used in decision making. A Node (Peer) can not use CUR/CUA message to notify the change in its own identity i.e. Origin-Host
  • Like CER/CEA message; CUR/CUA message can not be relayed, proxied and redirected.
Your Comments /Suggestions and Questions are always welcome,  shall clarify with best of our knowledge. So feel free to put Questions.
36 comments:

DIAMETER Connection Establishment




Most of the issue arises with DIAMETER Connection Establishment, here we are giving some view on how does DIAMETER Connection take place. As we know; Diameter is an application layer protocol, therefore virtually we could distinguish into two connections.
1) Transport Connection
2) DIAMETER connection


1) Transport Connection:

When ever a DIAMETER Application comes up (Client/Server) first of all it brings its transport connection which can be TCP/SCTP  on Port 3868 (By Default)or TLS/DTLS on PORT 5868 (By Default)( if security is applied). Before moving further we must check that Transport Connection is UP. For this we could check the message s that are exchanged during TCP/SCTP or TLS/DTLS connection establishment.


2) DIAMETER Connection

Once the Transport Connection is properly set up then Application initiates DIAMETER connection, For this First message that is triggered; is CER (Capabilities-Exchange-Request) with all supported application Ids. DIAMETER Connection said to be established when an Application receives CEA (Capabilities-Exchange-Answer) with Result-Code set to DIAMETER_SUCCESS. 

According to RFC-6733 When secure transport is established then all messages shall be exchanged on secured transport including CER/CEA.
Your Comments /Suggestions and Questions are always welcome,  shall clarify with best of our knowledge. So feel free to put Questions.
60 comments:
Subscribe to: Posts (Atom)