The ELP protocol is defined as a Vendor Specific diameter application (SLg application). It reuses the basic mechanisms defined by the Diameter base protocol as specified in IETF RFC 6733 , and it defines a number of additional commands and AVPs to implement the SLg, Lgd specific procedures.
The Diameter base protocol as specified in IETF RFC 6733  shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as described in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified.
For secure transport of Diameter messages, see TS 33.210
Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the SLg, Lgd interfaces.
Between the MME and the GMLC and between the SGSN and the GMLC, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server.
The Diameter base protocol as specified in IETF RFC 6733  includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions.
The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 . As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses.
Diameter messages over the SLg and Lgd interfaces shall make use of SCTP (see IETF RFC 4960 ).
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
Destination-Realm AVP shall always be included in all diameter requests, and therefore is declared as mandatory in the ABNF for all commands.
When a request is initiated by the GMLC, the name of the MME or SGSN shall be determined by querying the HSS over the SLh interface, and retrieve the specific MME or SGSN that is currently serving the UE. Therefore, Destination-Host AVP shall always be included in the commands originated at the GMLC, and is declared as mandatory in the ABNF.
When a request is initiated by the MME or SGSN, the name of the GMLC may be either locally configured in the MME/SGSN (e.g., in the intra-domain scenario, when the GMLC belongs to the same PLMN as the MME/SGSN), or it is known from a previously received location procedure initiated at the GMLC. Therefore, the Destination-Host AVP is declared as mandatory in the ABNF of the commands originated at the MME or SGSN.
If the Vendor-Specific-Application-ID AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes.
The MME, SGSN and GMLC shall advertise support of the Diameter SLg Application by including the value of the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETF RFC 6733 .