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 notEIR 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:

  1. Is the Vendor-Specific-Application-Id AVP mandatory?

    ReplyDelete
    Replies
    1. Hi Subhasish

      The Vendor-Specific-Application-ID is included as an optional AVP in all commands in order to ensure interoperability with diameter agents following a strict implementation of IETF RFC 3588 , by which messages not including this AVP will be rejected. IETF RFC 3588 indicates that the AVP shall be present in all proxiable commands, such as those specified here, despite that the contents of this AVP are redundant since the Application ID is already present in the command header. This AVP may be removed in subsequent revisions of this specification, once the diameter base protocol is updated accordingly.


      Thanks for your query.
      Happy to help you again
      Team-Diameter

      Delete
  2. Thanks for this post is very informative and interesting.all the points are very useful. Simple but very effective writing. Thanks for sharing such a nice post.


    Packers and Movers ECR

    ReplyDelete
  3. hi team.
    FIRST THANKS FOR YOUR DETAILS/EXPLANATION
    please we have link between SGSN via STP to EIR and also link between EIR and MME.The problem is when eir respond status as blacklisted,sgsn receive it as whitelisted(which means the phone is blacklisted on voice and sms but subscriber will still get data service)
    please any one with solution please help.

    ReplyDelete
    Replies
    1. Hi Peter,

      I couldn't get your this statement of your question -"The problem is when eir respond status as blacklisted,sgsn receive it as whitelisted".
      Do you mean:
      1. EIR sends "whitelisted" status to STP but SGSN receives it as "blacklisted"?[This is not possible as STP doesn't modify MAP part]
      2. EIR sends "blacklisted" status to MME but "whitelisted" status to SGSN?

      Can you please elaborate this.

      Delete
  4. Hi every one ..i need a complete details on S13/s13' Diameter protocol thats from where 3gpp tooks these information ECR & ECA Messages ...i need a complete documents only on s13/s13' ECR and ECA..it will be very helpful for my Research...

    ReplyDelete
    Replies
    1. Hi

      3gpp 29272 shall help you.


      Thanks for your query.
      Happy to help you again
      Team-Diameter

      Delete
  5. How the S13 choose the eir of home location? Pls explain

    ReplyDelete
    Replies
    1. Hi

      HSS and EIR always be of HOME. there is no other provision.


      Happy to help you again.
      Team-Diameter

      Delete
  6. Hello experts, I'm having a problem while filtering in Wireshark diameter requests (ME-Identity-Check-Request) and answers (ME-Identity-Check-Answer). The problem is that I have 40% more Answers than requests and I'm wondering what might be wrong in my filters.
    These are the filters used:
    diameter.cmd.code == 324 && diameter.answer_in
    diameter.cmd.code == 324 && diameter.answer_to

    Can someone shed some light? I'm trying to do a count of Reqs and answers in order to get a Ratio that can trigger actions.

    Thanks!

    ReplyDelete
    Replies
    1. Kindly try with diameter.cmd.code == 324  only

      Delete
  7. Hi team!
    Thanks for your article. It was very interesting. I have one question for you - how many bytes occupies this transaction (equipment status check) in DIAMETER? Previously in SIGTRAN it was about 460 bytes (IMEI check). I need this value for dimension transport bandwidth of S13 interface.

    P.S. Sorry for my English.

    ReplyDelete
  8. ME-Identity-Check-Request is not captured in wireshark. do i need to enable something in wireshark for this ?
    Thanks

    ReplyDelete