- LTE/IMS reference

Diameter (Based protocol)

Diameter is not a 3GPP protocol , it is a IEEE protocol. But It is a Based protocol. On top of diameter many other application protocols can actually exchanged the information like S6a, Gx , Gy etc. So these application protocols may be 3GPP standard or may be IEEE standard.

Diameter works on many interface- ( EPC and IMS)

Normal application how data will be travelled?

For normal procedure data will be travelled from router to another router and at last reached to destination. If we want to send the data from source to destination, the fundamental need is IP address. But how do we find the destination address? By DNS server. So, from DNS server we will find out the destination IP address and by using IP actually we will send the IP packets.

But if DNS is not in a placed, then how do we get the IP address ? We should know the manually. That means we should know destination IP address. For example , if we send the FTP data, then we should know the FTP server IP address manually.

Diameter is actually between MME and HSS. But if MME and HSS belongs to same operator, operator configure the MME IP address in HSS and HSS IP address in MME, then communication works. Because based on IP address we can established the SCTP association , then diameter message can flow.

But assume a case where mobile equipment can visiting a place like Italy, Germany etc. So MME (visiting) need to talk to our

HSS (Mumbai) to get the profile information. We can also configure the IP address by manually like Italy MME IP address in Mumbai HSS and similarly Mumbai HSS IP address in Italy MME. But how many system we can configure? So every Italy MME should know the Mumbai HSS IP address. Because Mumbai Guy can go anywhere. So, this is not a practical case where every system’s IP address should know the each other.

So, how do we know the IP address? By D.N.S query we can get the IP address but there is another issue in DNS server.

If we see the Diameter protocol stack, Diameter is actually running on SCTP. SCTP is a transport protocol but SCTP is a connection oriented. That means Mumbai 1000 different people is going to 1000 different places, these 1000 MME’s will have made SCTP association with HSS. But what is the issue? The issue is how many SCTP association/ connection can MME maintain or HSS maintain ? HSS need to maintain 1000 of SCTP connection. If very large number of SCTP connection is made in HSS, HSS load will increase. He won’t be able to perform perfectly. Too many SCTP association is there But if the user is staying there , that association need to be continued till the user is in attached state between MME and HSS. So this is not a practical case because connection oriented problem. So how do we solve this problem ? All the Diameter components would be connected to a component called as DRA( Diameter routing agent). So HSS would be connected to the DRA. DRA can read the Diameter message and it forwards to the next DRA and so on. So, every MME not directly connected to all HSS, is connected through DRA.

Network level routing/ Application level routing ?

If we want to send Diameter message from MME to HSS, source IP address is MME and destination IP address is HSS. So Diameter packet is never be open up anywhere. Diameter packet is kept up in SCTP, SCTP is kept inside IP, IP has got one source IP address(MME) and destination IP address(HSS). So directly IP packet is arrived in HSS. That is actually called as network level routing.

But there is some drawback in network level routing because there may be who act like a MME and get the data from HSS. So don’t want to take that because security related issue. So, how do we solve this issue? By using application level routing.

In application level routing the component called DRA. Actually when we are sending the message, the source IP address is MME and destination IP address is DRA. The duty of DRA is, he will open up the IP packet, take out the SCTP packet ,read the packet and based on that he decided to send out to next DRA and so on. Finally it reached to the destination (HSS). So the message will travelling through the DRA.

Functions of Diameter-

1)Delivery of AVP’s (Attribute value pairs)- Pairs means two. Attribute means name and its value.

In 3GPP we called it IE(information element) but in IEEE it is called AVPs. AVP contains attribute name +value. But these AVP is developed in TLV ( Type Length Value) format. So each AVP explain about itself what is the name of it, what is the value and what is the length of it.

But two types of AVPs- one is AVPs belongs to Diameter protocol and other one is AVPs which are application specific.

In Diameter message , we have a diameter header followed by many AVPs . But in these AVPs some of the AVPs are used for the Diameter header purpose and some of the AVPs are used for the application purpose like Gx,Rx, Gz…etc.

2) Capabilities negotiation- When two diameter component are talking to each other ,the first activity they do capability negotiation . MME goes and tell to DRA that he can support one application protocol like S6a .DRA tell to MME that he can support S6a, Gx, Rx, Gz…etc because DRA actually connected to many component.

3) Error notification

4) Extensibility, through addition of new commands and AVPs (required in [AAAREQ]).

Diameter protocol is defined to be extensible using different mechanisms including –

- Defining new AVPs value.

- Creating new AVPs .

- Creating new Authentication Authorization Application(AAA).

- Creating new accounting application.

5) Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user.

6) Transporting of service specific authorization information , between client and servers, allowing the peers to decide whether a

user's access request should be granted.

7) Exchanging resource usage information, which MAY be used for accounting purposes, capacity planning, etc.

8) Relaying, proxying and redirecting of Diameter messages through server hierarchy.

Diameter connection and session-

The Relay agent(DRA) is between client and server. So there is two SCTP association ,one is between client and Relay ,second one is between Relay and server. But number of user session is one. User session is existing between client and server. But connection are existing between client to DRA and DRA to server. There may be 50 DRA present in between client and server. So total number of component including client and server is 52. So , 51 connection will have between client and server but information will be forwarded through many DRA.

Diameter Agents-

There are 3 types of Diameter agent-

1)Redirect agents

2)Relay agents

3)Proxy agents

When we send the diameter message to Redirect agents, he will read the address and he will try to find out where the message need to be forwarded. He gives the address of the DRA. His not duty to forwarding the packets.

But if it is Proxy agent, he will forward it. Relay agent is also forward it. But different between Relay agent and Proxy agent is Proxy agent will remember every thing that is transaction state as well as session state but Relay agent forget what is happening , he will remember only transaction state not session state.

So, all these things are whether it Relay agent , Proxy agent or Redirect agent that is DRA’s. The main duty is to forward the diameter message or some how help the diameter message to reach the destination.

How the message is going to Destination ?

With the help of Diameter routing the messages are going to destination. Once it goes to destination component ,he definitely reply back. If the reply is coming back we no need to required IP address for response message, instead of that the response message going to same path in the reverse direction. So, if the response message travelled in the reverse direction , everybody in the middle who have received this request message must be maintain a linking b/w this request and for that this is response. So, everybody must be maintain a linking . That linking is actually called as Transaction state. There will be two transaction state. One is incoming transaction and second one is outgoing transaction. But for outgoing transaction there will be incoming response.

So, for this purpose , there will be two header fields are there. One is session id and other is transaction id. Session id will not change. Session id will be created by client and it goes to the server. Session id will be maintained but transaction id is only between client and DRA. If DRA changes, the transaction id may changes.

Above example-

Session id 18 and transaction id 255. Now these message client is going to send DRA1. DRA1 is going to send DRA2. But when DRA1 is forwarding to DRA2, he have to keep the session id same session id but he might have to changed the transaction id.

But he might be using suppose 375. Now DRA1 should maintain the linking between these two transaction id 255 & 375. Now when he send the message to DRA2, he received this number 375. And he might be using another number 475. This 475 number will forward to server . When server reply back , he will use this transaction id 475. So, DRA2 remove this transaction id 475 and put in the transaction id 375, forward to DRA1. DRA1 remove this transaction id 375 and put in the transaction id 255, forward to client. So client understand that he has got response of that transaction id 255.

Translation Agents-

Diameter Header-

Diameter header is common for any diameter message interface.

Version- This Version field must be set to 1 to indicate Diameter Version 1.

Message Length-

The Message Length field is three octets (24 bits) and indicates the length of the Diameter message including the header fields. So maximum diameter message can up to 2 ^24 -1 ( 1,67,77,215 size ).

Command Code-

The command code size is 24 bits. So, 2^24 commands are there. But command code is normally unique in all the Interfaces like S6a, Gx, Gy, Gz etc. So, every interfaces we have every set of command codes.

Example- On S6a interface we have totally 9 command codes are there. On every command there is one request and response message. Totally we have diameter 18 diameter messages in S6a interface. But command code is 9 (not 18). Because request and response will have only one code not two codes. But how do we differentiate whether it is request or response? By using command flag R. If R=1, meaning is ‘request’, if R=0, meaning is ‘response’.

Application Id-

Application-ID is four octets (32 bits) and is used to identify to which application the message is applicable for. So, total number of application can run up to 2^32. Every different interfaces will have one unique id. It is indirectly recognized in what interface diameter messages are there. Application id for S6a is 16777251.

Hop to hop Identifier:

Hop to hop Identifier is for transaction. Transaction is between one element to next diameter element. Hop to hop Identifier will keep on changing on every interface b/w two DRA.

End to end identifier-

This is for session. This is not change. This is between client and server.

Command Flags-

The Command Flags field is eight bits. The following bits are assigned:

The small r is reserved for future purpose.

Request (R)- tells whether it is request or response. If R=1, it is request message, if R=0, it is response(answer) message . But command code is same.

P(Proxiable) - is proxiable or not. If set(P=1), the message may be proxied , relayed or redirected. If cleared (P=0), the message must locally processed.

Error( E)- If set, the message(Response/answer) contains a protocol error. This bit must not be set in request messages.

T(Potentially re-transmitted message)- This bit must be cleared (T=0), when sending a request for the first time. If T=1, it is retransmitted message. Potentially means sender Guy point of view, this is retransmitted message but receiving Guy point of view, this may not be not be retransmitted message (Duplicate message) because if link failure happened the message may not be reached to the destination . So sender point of view it is transmitting second time but receiver point of view it may be or may not be.

AVP’s- (Attribute value pair’s):

AVP Code- Total bits for AVP code is 32 bits. So total AVP code is 2^32-1 (4294967296-1).

The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter purpose.

AVP Length- The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute length, the message should be rejected.

Vendor ID- Vendor id is optional. How do we know whether vendor id is optional ? By using Flag (V). If V=1, then vendor id is present else not present and followed by data. Data is nothing but AVP related information . One AVP can contain one information or may many information. But vendor id is actually filled with different organization who are register with IEEE Diameter component. The different Vendor id (3GPP , 3GPP2, IETF etc.) will tell which organization belongs to.

Flags-

If V=1, then vendor id will be present else not present.

M tells it is mandatory AVP or not.

If P=1, Client is asking for end to end security else client is asking for server side security.

r is for future purpose.

Below the command/messages are applicable on every interface-

All the above commands are applicable on all the interfaces.

Diameter Base protocol AVPs.

The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values an whether the AVP may be encrypted. For the originator of a Diameter message, "Encr" (Encryption) means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message must not be sent unless there is end-to-end security between the originator and the recipient and integrity /confidentiality protection is offered for this AVP OR the originator has locally trusted configuration that indicates that end-to-end security is not needed. Similarly, for the originator of a Diameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message must not be sent unless there is end-to-end security between the originator and the recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed.

Command Code- (Message format)

Capabilities-Exchange-Request-

Message Format

{ Origin-Host }

{ Origin-Realm }

1* { Host-IP-Address }

{ Vendor-Id }

{ Product-Name }

[ Origin-State-Id ]

* [ Supported-Vendor-Id ]

* [ Auth-Application-Id ]

* [ Inband-Security-Id ]

* [ Acct-Application-Id ]

* [ Vendor-Specific-Application-Id ]

[ Firmware-Revision ]

* [ AVP ]

Capabilities-Exchange-Answer

Message Format

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

1* { Host-IP-Address }

{ Vendor-Id }

{ Product-Name }

[ Origin-State-Id ]

[ Error-Message ]

* [ Failed-AVP ]

* [ Supported-Vendor-Id ]

* [ Auth-Application-Id ]

* [ Inband-Security-Id ]

* [ Acct-Application-Id ]

* [ Vendor-Specific-Application-Id ]

[ Firmware-Revision ]

* [ AVP ]

Device-Watchdog-Request

Message Format

{ Origin-Host }

{ Origin-Realm }

[ Origin-State-Id ]

Device-Watchdog-Answer

Message Format

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ Error-Message ]

* [ Failed-AVP ]

[ Original-State-Id ]

Disconnect-Peer-Request

Message Format

{ Origin-Host }

{ Origin-Realm }

{ Disconnect-Cause }

Re-Auth-Request

Message Format

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ User-Name ]

[ Origin-State-Id ]

* [ Proxy-Info ]

* [ Route-Record ]

* [ AVP ]

Re-Auth-Answer

Message Format

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

* [ Failed-AVP ]

* [ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Host-Cache-Time ]

* [ Proxy-Info ]

* [ AVP ]

Abort-Session-Request

Message Format

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

[ User-Name ]

[ Origin-State-Id ]

* [ Proxy-Info ]

* [ Route-Record ]
* [ AVP ]

Abort-Session-Answer

Message Format

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

* [ Failed-AVP ]

* [ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

* [ Proxy-Info ]

* [ AVP ]

Accounting-Request

Message Format

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Accounting-Record-Type }

{ Accounting-Record-Number }

[ Acct-Application-Id ]

[ Vendor-Specific-Application-Id ]

[ User-Name ]

[ Accounting-Sub-Session-Id ]

[ Acct-Session-Id ]

[ Acct-Multi-Session-Id ]

[ Acct-Interim-Interval ]

[ Accounting-Realtime-Required ]

[ Origin-State-Id ]

[ Event-Timestamp ]

* [ Proxy-Info ]

* [ Route-Record ]

* [ AVP ]

Accounting-Answer

Message Format

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

{ Accounting-Record-Type }

{ Accounting-Record-Number }

[ Acct-Application-Id ]

[ Vendor-Specific-Application-Id ]

[ User-Name ]

[ Accounting-Sub-Session-Id ]

[ Acct-Session-Id ]

[ Acct-Multi-Session-Id ]

[ Error-Reporting-Host ]

[ Acct-Interim-Interval ]

[ Accounting-Realtime-Required ]

[ Origin-State-Id ]

[ Event-Timestamp ]

* [ Proxy-Info ]
* [ AVP ] Update-Location-Request-

The Update Location Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to update location information in the HSS.

It contains Diameter header followed by many AVPs.

Message format-

< Session-Id >

{Authentication session state}

{Origin Host}

{Origin Realm}

{Destination Host}

{Destination Realm}

{User name}

{Supported Features (vendor id)}

{RAT type (E-utran) }

{Visited PLMN ID}

Note-

When receiving an Update Location request the HSS shall check whether the IMSI is known.

If it is not known, a Result Code of DIAMETER_ERROR_USER_UNKNOWN is returned.

If it is known, but the subscriber has no EPS subscription, the HSS may (as an operator option) return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION.

The HSS shall check whether the RAT type the UE is using is allowed. If it is not, a Result Code of DIAMETER_ERROR_RAT_NOT_ALLOWED is returned.

The HSS shall check whether roaming is not allowed in the VPLMN due to ODB. If so a Result Code of DIAMETER_ERROR_ROAMING_NOT_ALLOWED is returned.

Update-Location-Answer-

The Update-Location-Answer (ULA) command, indicated by the Command-Code field set to 316 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN.

Message format-

< Session-Id >

{ vendor specific Application ID}

{Authentication Application ID}

{Result Code (Diameter success )}

{Authentication session state}

{Origin Host}

{Origin Realm}

{Supported Features (vendor id)}

{Subscription-Data}

-MSISDN , Network Access Mode(only packet), 3GPP charging characteristics, AMBR, Max- Requested- UL,

Max- Requested- DL.

{APN Configuration}

- PDN type( IPV4 or IPV6), Service selection, EPS_Suscriber_QOS_Profile (QCI-9), ARP(Priority-1), Pre-emption

capability, pre-emption-Vulnerability, VPLMN-Dynamic-Address-Allowed (Allowed), MIP6-Agent-Info,
Destination Realm, Destination Host, PDN –GW-Allocation –Type( Dynamic),
3GPP charging characteristics, AMBR, Max-Requested- UL, Max- Requested- DL

Example-

Update-Location-Request-

Update-Location-Answer-

Cancel-Location-Request-

CLR (Cancel-Location-Request) triggered by HSS in following scenarios.

1) Subscription is withdrawal for a user (IMSI).

2) To inform previous MME/SGSN about change in location.

3) To inform MME/SGSN about initial attach.

There could be 3 kinds of control nodes

1) Stand-alone MME

2) Stand-alone SGSN

3) Combined MME/SGSN

The Cancel-Location-Request (CLR) command, indicated by the Command-Code field set to 317 and

the 'R' bit set in the Command Flags field, is sent from HSS to MME or SGSN.

Message Format

< Cancel-Location-Request> ::= < Diameter Header: 317, REQ, PXY, 16777251 >

< Session-Id >

[ Vendor-Specific-Application-Id ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

{ User-Name }

*[ Supported-Features ]

{ Cancellation-Type }

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Cancel-Location-Answer -

The Cancel-Location-Answer (CLA) command, indicated by the Command-Code field set to 317 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Cancel-Location-Answer> ::= < Diameter Header: 317, PXY, 16777251 >

< Session-Id >

[ Vendor-Specific-Application-Id ]

*[ Supported-Features ]

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

*[ AVP ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ] Authentication-Information-Request -

Authentication is a Major function of HSS/AuC. AIR/AIA is an important and first message on s6a/s6d interface that has been exchange between MME/SGSN and HSS during very first attach procedure. Here MME/SGSN asks for authentication credentials from HSS usually called as Authentication Vectors to authenticate and authorize the subscriber.

It contains Diameter header followed by many AVPs.

Message format-

< Session-Id >

{Authentication session state}

{Origin Host}

{Origin Realm}

{Destination Host}

{Destination Realm}

{User name}

{Supported Features (vendor id)}

{Requested _Utran_ Authentication information}

{Immediate Response Preferred}

{Requesting Node type

Authentication-Information-Answer-

The Authentication-Information-Request (AIR) command, indicated by the Command-Code field set to tbd and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Authentication-Information-Request> ::= < Diameter Header: tbd, REQ, PXY, tbd >

< Session-Id >

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ Destination-Host ]

{ Destination-Realm }

{ User-Name }

*[Supported-Features]

[ Requested-EUTRAN-Authentication-Info ]

-RANDOM number, XRES Number, Authentication number, Authentication Algo.Info., KASME (key for ciphering and Integrity purpose.

[ Requested-UTRAN-GERAN-Authentication-Info ]

{Result code (Diameter success)}

{ Visited-PLMN-Id }

{ Requesting-Node-Type }

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Example-

Authentication Information Request-

Authentication Information Answer-

Insert-Subscriber-Data-Request –

IDR/IDA messages are used between HSS and MME/SGSN. HSS triggers IDR for any of the following reasons (it is assumed that UE is attached (Purged is not performed in MME/SGSN))

1) If there is an administrative change in subscription of an attached subscriber.

2) To apply, change or remove operator determined barring to a subscriber

3) To activate Trace for a subscriber

4) To get Location information and/or State information from MME of a subscriber

5) To know the local time zone of the visited PLMN (network location)

6) To get T-ADS (Terminating Access Domain Selection) information of UE i.e UE's last radio activity time, associate Radio Access Type (RAT) and whether current TA/RA supports IMS voice over PS session or not.

Message Format

< Insert-Subscriber-Data-Request> ::= < Diameter Header: 319, REQ, PXY, 16777251 >

< Session-Id >

[ Vendor-Specific-Application-Id ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

{ User-Name }

*[ Supported-Features]

{ Subscription-Data}

[ IDR-Flags ]

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Insert-Subscriber-Data-Answer-

The Insert-Subscriber-Data-Answer (IDA) command, indicated by the Command-Code field set to 319

and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777251 >

< Session-Id >

[ Vendor-Specific-Application-Id ]

*[ Supported-Features ]

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ IMS-Voice-Over-PS-Sessions-Supported ]

[ Last-UE-Activity-Time ]

[ RAT-Type ]

[ IDA-Flags ]

[ EPS-User-State ]

[ EPS-Location-Information ]

*[ AVP ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record

Delete-Subscriber-Data-Request-

It is invoked by HSS only when Subscriber is attached and some data is deleted at HSS. Now HSS informs MME with this message that some part of subscription data is deleted at HSS.

The Delete-Subscriber Data-Request (DSR) command, indicated by the Command-Code field set to 320 and the 'R' bit set in the Command Flags field, is sent from HSS to MME or SGSN.

Message Format

< Delete-Subscriber-Data-Request > ::= < Diameter Header: 320, REQ, PXY, 16777251 >

< Session-Id >

[ Vendor-Specific-Application-Id ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

{ User-Name }

*[ Supported-Features ]

{ DSR-Flags }

*[ Context-Identifier ]

[ Trace-Reference ]

*[ TS-Code ]

*[ SS-Code ]

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record

Delete-Subscriber-Data-Answer-

The Delete-SubscriberData-Answer (DSA) command, indicated by the Command-Code field set to tbd and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Delete-Subscriber-Data-Answer> ::= < Diameter Header: tbd, PXY, tbd >

< Session-Id >

*[ Supported-Features ]

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ DSA-Flags ]

*[ AVP ] 3GPP

Release 8 33 3GPP TS 29.272 V8.1.1 (2009-01)

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Purge-UE-Request -

MME informs the HSS that UE is inactive for a long period that is why MME has deleted the Subscription Data received in previous ULR from its end.

The Purge-UE-Request (PUR) command, indicated by the Command-Code field set to tbd and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Purge-UE-Request> ::= < Diameter Header: tbd, REQ, PXY, tbd >

< Session-Id >

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ Destination-Host ]

{ Destination-Realm }

{ User-Name }

*[ Supported-Features ]

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Purge-UE-Answer -

The Purge-UE-Answer (PUA) command, indicated by the Command-Code field set to tbd and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN.

Message Format

< Purge-UE-Answer> ::= < Diameter Header: tbd, PXY, tbd >

< Session-Id >

*[ Supported-Features ]

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ PUA-Flags ]

*[ AVP ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Notify-Request-

MME stores PDN address and other attach information at HSS.

The Notify-Request (NOR) command, indicated by the Command-Code field set to tbd and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Notify-Request> ::= < Diameter Header: tbd, REQ, PXY, tbd >

< Session-Id >

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ Destination-Host ]

{ Destination-Realm }

{ User-Name }

* [ Supported-Features ]

[ Terminal-Information ]

[ PDN-GW-Identity ]

[Service-Selection]

[ NOR-Flags ]

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Notify-Answer-

The Notify-Answer (NOA) command, indicated by the Command-Code field set to tbd and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN.

Message Format

< Notify-Answer> ::= < Diameter Header: tbd, PXY, tbd >

< Session-Id >

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

*[ Supported-Features ]

*[ AVP ] 3GPP

Release 8 35 3GPP TS 29.272 V8.1.1 (2009-01)

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Reset Request -

Invoked by HSS, to inform MME that HSS goes down for some time, kindly sync the data and send fresh location/PDN information at HSS. Reset request can be send by either MME or HSS who goes down.

The Reset-Request (RSR) command, indicated by the Command-Code field set to tbd and the 'R' bit set in the Command Flags field, is sent from HSS to MME or SGSN.

Message Format

< Reset-Request> ::= < Diameter Header: tbd, REQ, PXY, tbd >

< Session-Id >

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

[ Supported-Features ]

*[ User-Id ]

*[ AVP ] 3GPP

Release 8 34 3GPP TS 29.272 V8.1.1 (2009-01)

*[ Proxy-Info ]

*[ Route-Record ]

Reset Answer -

Reset-Answer (RSA) Command

The Authentication-Information-Answer (RSA) command, indicated by the Command-Code field set to tbd and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS.

Message Format

< Reset-Answer> ::= < Diameter Header: tbd, PXY, tbd >

< Session-Id >

[ Supported-Features ]

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

*[ AVP ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

ME Identity check request- ( B/w MME and EIR)

This messages are used between MME and EIR. MME triggers ECR for checking of the validity of an equipment used by a subscriber . That means User is either White list , Black List or Grey list.

(0)White list :- An authenticated equipment.

(1)Black list :- It is stolen; services need to be terminated.

(2)Grey list :- It is the intermediate state of whitelist and blacklist. Telecom operator can use this state proprietorially like activate tracing for equipment etc.

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]

ME Identity check Answer-

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 ]

More information pending to be updated

LTE/IMS reference

No comments:

Pages

Follow Us

Search This Blog

About Me

Contact Form

Total Pageviews

Random Posts

Tags

Latest Admit Cards

Recent Posts