DIAMETER: How does a node support multiple diameter applications ?

Question

I have a very generic question. I took PCEF to describe my problem.
PGW supports multiple diameter based applications like Gx, Gy and Gz. When a message receives at PCEF from the peer diameter entities, how does PCEF come to know source of message and after that what PCEF does to forward this message to the proper application running at the PCEF.

My question is implementation specific. Please provide inputs in details.

I also want to know about session termination in Diameter protocol. Again, I am considering PCEF to describe my question. When a session is established between PCEF and PCRF ? either (CER and CEA) or (CCR and CCA) ?

Answer 1

As to generic question.
You have to go and read about realms and peers in Diameter.
Based on my hands-on experience, the Gy and Gx/Gz were always from different realms - this is how PCEF know where form he got the message.
Everyone please correct my if I'm wrong or give your inputs.

As to the CCR-I and CCA-I you have to go back to the basic attach procedure. You can find this on my blog here
http://www.lteandbeyond.com/2012/01/lte-attach-procedure.html

Answer 2

Not sure if I understood the question correctly -

Just check the CCR message

<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
                                   < Session-Id >
                                   { Origin-Host }
                                   { Origin-Realm }
                                   { Destination-Realm }
                                   { Auth-Application-Id }
                                   { Service-Context-Id }
                                   { CC-Request-Type }
                                   { CC-Request-Number }
                                   [ Destination-Host ]
                                   [ User-Name ]
                                   [ CC-Sub-Session-Id ]
                                   [ Acct-Multi-Session-Id ]
                                   [ Origin-State-Id ]
                                   [ Event-Timestamp ]
                                  *[ Subscription-Id ]
                                   [ Service-Identifier ]
                                   [ Termination-Cause ]
                                   [ Requested-Service-Unit ]
                                   [ Requested-Action ]
                                  *[ Used-Service-Unit ]
                                   [ Multiple-Services-Indicator ]
                                  *[ Multiple-Services-Credit-Control ]
                                  *[ Service-Parameter-Info ]
                                   [ CC-Correlation-Id ]
                                   [ User-Equipment-Info ]
                                  *[ Proxy-Info ]
                                  *[ Route-Record ]
                                  *[ AVP ] 

Which contains the application-id (the same is already negotiated in CER/CEA) which can be used by the PCEF or any other node which is supporting diameter.

Subsequent diameter message in the case of stateless scenarios may not contain the app-id but the same thing diameter can retrieve from session context.

Coming to your second question, session termination is done via the STR.