6 Protocol Specification and Implementation
29.3453GPPInter-Proximity-services (Prose) function signalling aspectsRelease 17Stage 3TS
6.1 Introduction
6.1.1 Use of Diameter base protocol
The Diameter Base Protocol as specified in IETF RFC 6733 [29] 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 specified in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified.
6.1.2 Securing Diameter Messages
For secure transport of Diameter messages, see 3GPP TS 33.210 [8].
6.1.3 Accounting functionality
Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the PC6/PC7 interfaces.
6.1.4 Use of sessions
Between the ProSe Functions, 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 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 [29]. 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.
6.1.5 Transport protocol
Diameter messages over the PC6/PC7 interfaces shall make use of SCTP IETF RFC 4960 [9].
6.1.6 Routing considerations
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
The Destination-Realm AVP shall contain the network domain name of the targeted ProSe Function. The network domain name is either known by the sending ProSe Function or derived from the PLMN-Id of the targeted ProSe Function to construct the EPC Home Network Realm/Domain, as indicated in 3GPP TS 23.003 [4], clause 19.2.
If a ProSe Function knows the address/name of the ProSe Function in charge of a given UE, and the associated network domain name, both the Destination-Realm and Destination-Host AVPs shall be present in the request.
If a ProSe Function knows only the network domain name, the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node.
Consequently, the Destination-Realm AVP is declared as mandatory and the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by a ProSe Function.
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.
6.1.7 Advertising Application Support
The ProSe Functions shall advertise support of the Diameter Inter ProSe Functions 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 [29].
6.1.8 Diameter Application Identifier
The Diameter Inter ProSe Functions Application protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.
The Diameter application identifier assigned to the Diameter Inter ProSe Functions application is 16777340 (allocated by IANA). The same Diameter application identifier is used over the PC6 interface and the PC7 interface.
6.1.9 Use of the Supported-Features AVP
When new functionality is introduced on the PC6/PC7 interfaces, it should be defined as optional. If backwards incompatible changes cannot be avoided, the new functionality shall be introduced as a new feature and support advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the PC6/PC7 interfaces is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [10].
When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.
As defined in 3GPP TS 29.229 [10], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specification, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another.
6.2 Commands
6.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described in this specification.
6.2.2 Command-Code values
This csublause defines Command-Code values for the Diameter Inter ProSe Functions application used over the PC6/PC7 interfaces as allocated by IANA.
Every command is defined by means of the ABNF syntax IETF RFC 5234 [11], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [29]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [29] shall apply.
The Vendor-Specific-Application-Id AVP shall not be included in any command sent by Diameter nodes supporting applications defined in this specification. 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.
NOTE: The Vendor-Specific-Application-Id is included as an optional AVP in all Command Code Format specifications defined in this specification in order to overcome potential interoperability issues with intermediate Diameter agents non-compliant with IETF RFC 6733 [29].
The following Command Codes are defined in this specification:
Table 6.2.2-1: Command-Code values for Diameter ProSe Inter Functions Application
|
Command-Name |
Abbreviation |
Code |
Clause |
|
ProSe-Authorization-Request |
PAR |
8388668 |
6.2.3 |
|
ProSe-Authorization-Answer |
PAA |
8388668 |
6.2.4 |
|
ProSe-Discovery-Request |
PDR |
8388669 |
6.2.5 |
|
ProSe-Discovery-Answer |
PDA |
8388669 |
6.2.6 |
|
ProSe-Match-Request |
PMR |
8388670 |
6.2.7 |
|
ProSe-Match-Answer |
PMA |
8388670 |
6.2.8 |
|
ProSe-Match-Report-Info-Request |
PIR |
8388671 |
6.2.9 |
|
ProSe-Match-Report-Info-Answer |
PIA |
8388671 |
6.2.10 |
|
ProSe-Proximity-Request |
PRR |
8388672 |
6.2.11 |
|
ProSe-Proximity-Answer |
PRA |
8388672 |
6.2.12 |
|
ProSe-Location-Update-Request |
PLR |
8388673 |
6.2.13 |
|
ProSe-Location-Update-Answer |
PLA |
8388673 |
6.2.14 |
|
ProSe-Alert-Request |
ALR |
8388674 |
6.2.15 |
|
ProSe-Alert-Answer |
ALA |
8388674 |
6.2.16 |
|
ProSe-Cancellation-Request |
PCR |
8388675 |
6.2.17 |
|
ProSe-Cancellation-Answer |
PCA |
8388675 |
6.2.18 |
For these commands, the Application-ID field shall be set to 16777340 (application identifier of the Diameter Inter ProSe Functions interface application, allocated by IANA).
6.2.3 ProSe-Authorization-Request (PAR) Command
The ProSe-Authorization-Request (PAR) Command, indicated by the Command-Code field set to 8388668 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function in Local PLMN/VPLMN.
Message Format
< ProSe-Authorization-Request > ::= < Diameter Header: 8388668, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ User-Identity }
{ Visited-PLMN-Id }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.4 ProSe-Authorization-Answer (PAA) Command
The ProSe-Authorization-Answer (PAA) Command, indicated by the Command-Code field set to 8388668 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in Local PLMN/VPLMN to the ProSe Function in the HPLMN.
Message Format
< ProSe-Authorization-Answer> ::= < Diameter Header: 8388668, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
[ ProSe-Direct-Allowed]
[ Validity-Time-Announce ]
[ Validity-Time-Monitor ]
[ Validity-Time-Communication ]
[ Authorized-Discovery-Range ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.5 ProSe-Discovery-Request (PDR) Command
The ProSe-Discovery-Request (PDR) Command, indicated by the Command-Code field set to 8388669 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function in Local PLMN.
Message Format
< ProSe-Discovery-Request > ::= < Diameter Header: 8388669, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ Discovery-Auth-Request }
[ Discovery-Entry-ID ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.6 ProSe-Discovery-Answer (PDA) Command
The ProSe-Discovery-Answer (PDA) Command, indicated by the Command-Code field set to 8388669 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in Local PLMN to the ProSe Function in the HPLMN.
Message Format
< ProSe-Discovery-Answer > ::= < Diameter Header: 8388669, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
[ Discovery-Auth-Response ]
[ Discovery-Entry-ID ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.7 ProSe-Match-Request (PMR) Command
The ProSe-Match-Request (PMR) Command, indicated by the Command-Code field set to 8388670 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function in Local PLMN.
Message Format
< ProSe-Match-Request > ::= < Diameter Header: 8388670, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ Match-Request }
[ PMR-Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.8 ProSe-Match-Answer (PMA) Command
The ProSe-Match-Answer (PMA) Command, indicated by the Command-Code field set to 8388670 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in Local PLMN to the ProSe Function in the HPLMN.
Message Format
< ProSe-Match-Answer > ::= < Diameter Header: 8388670, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Match-Report ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.9 ProSe-Match-Report-Info-Request (PIR) Command
The ProSe-Match-Report-Info-Request (PIR) Command, indicated by the Command-Code field set to 8388671 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN of the monitoring UE to the ProSe Function of the PLMN in which the announcing UE is roaming.
Message Format
< ProSe-Match-Report-Info-Request > ::= < Diameter Header: 8388671, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ Match-Report-Info }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.10 ProSe-Match-Report-Info-Answer (PIA) Command
The ProSe-Match-Report-Info-Answer (PIA) Command, indicated by the Command-Code field set to 8388671 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function of the PLMN in which the announcing UE is roaming to the ProSe Function in the HPLMN of the monitoring UE.
Message Format
< ProSe-Match-Report-Info-Answer > ::= < Diameter Header: 8388671, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.11 ProSe-Proximity-Request (PRR) Command
The ProSe-Proximity-Request (PRR) Command, indicated by the Command-Code field set to 8388672 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function of another PLMN.
Message Format
< ProSe-Proximity-Request > ::= < Diameter Header: 8388672, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ PRR-Flags }
{ Requesting-EPUID }
{ Targeted-EPUID }
{ Time-Window }
{ Location-Estimate }
[ Location-Update-Trigger ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.12 ProSe-Proximity-Answer (PRA) Command
The ProSe-Proximity-Answer (PRA) Command, indicated by the Command-Code field set to 8388672 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function of another PLMN.
Message Format
< ProSe-Proximity-Answer > ::= < Diameter Header: 8388672, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
[ Location-Estimate ]
[WLAN-Link-Layer-Id ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.13 ProSe-Location-Update-Request (PLR) Command
The ProSe-Location-Update-Request (PLR) Command, indicated by the Command-Code field set to 8388673 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function of another PLMN.
Message Format
< ProSe-Location-Update-Request > ::= < Diameter Header: 8388673, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ Targeted-EPUID }
{ Location-Estimate }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.14 ProSe-Location-Update-Answer (PLA) Command
The ProSe-Location-Update-Answer (PLA) Command, indicated by the Command-Code field set to 8388673 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function of another PLMN.
Message Format
< ProSe-Location-Update-Answer > ::= < Diameter Header: 8388673, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.15 ProSe-Alert-Request (ALR) Command
The ProSe-Alert-Request (ALR) Command, indicated by the Command-Code field set to 8388674 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function of another PLMN.
Message Format
< ProSe-Alert-Request > ::= < Diameter Header: 8388674, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ App-Layer-User-Id }
{ Targeted-EPUID }
[ Assistance-Info ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.16 ProSe-Alert-Answer (ALA) Command
The ProSe-Alert-Answer (ALA) Command, indicated by the Command-Code field set to 8388674 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function of another PLMN.
Message Format
< ProSe-Alert-Answer > ::= < Diameter Header: 8388674, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.17 ProSe-Cancellation-Request (PCR) Command
The ProSe-Cancellation-Request (PCR) Command, indicated by the Command-Code field set to 8388675 and the "R" bit set in the Command Flags field, is sent from the ProSe Function in the HPLMN to the ProSe Function in a local/visited PLMN.
Message Format
< ProSe-Cancellation-Request > ::= < Diameter Header: 8388675, REQ, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
{ Requesting-EPUID }
{ Targeted-EPUID }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.18 ProSe-Cancellation-Answer (PCA) Command
The ProSe-Cancellation-Answer (PCA) Command, indicated by the Command-Code field set to 8388675 and the "R" bit cleared in the Command Flags field, is sent from the ProSe Function in a local/visited PLMN to the ProSe Function in the HPLMN.
Message Format
< ProSe-Cancellation-Answer > ::= < Diameter Header: 8388675, PXY, 16777340 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.3 Information Elements
6.3.1 General
The following table (table 6.3.1-1) specifies the Diameter AVPs defined for the PC6/PC7 interfaces, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415).
For all AVPs which contain bit masks and are of the type Unsigned32 e.g., PRR-Flags, bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 shall be used.
Table 6.3.1-1: PC6/PC7 specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
App-Layer-User-Id |
3801 |
6.3.2 |
UTF8String |
M, V |
No |
|||
|
Assistance-info |
3802 |
6.3.3 |
Grouped |
M, V |
No |
|||
|
Assistance-Info-Validity-Timer |
3803 |
6.3.4 |
Unsigned32 |
M, V |
No |
|||
|
Discovery-Type |
3804 |
6.3.5 |
Unsigned32 |
M, V |
No |
|||
|
Filter-Id |
3805 |
6.3.9 |
OctetString |
M, V |
No |
|||
|
MAC-Address |
3806 |
6.3.11 |
UTF8String |
M, V |
No |
|||
|
Match-Report |
3807 |
6.3.12 |
Grouped |
M, V |
No |
|||
|
Operating-Channel |
3808 |
6.3.14 |
Unsigned32 |
M, V |
No |
|||
|
P2P-Features |
3809 |
6.3.15 |
Unsigned32 |
M, V |
No |
|||
|
ProSe-App-Code |
3810 |
6.3.16 |
OctetString |
M, V |
No |
|||
|
ProSe-App-Id |
3811 |
6.3.17 |
UTF8String |
M, V |
No |
|||
|
ProSe-App-Mask |
3812 |
6.3.18 |
OctetString |
M, V |
No |
|||
|
ProSe-Discovery-Filter |
3813 |
6.3.20 |
Grouped |
M, V |
No |
|||
|
PRR-Flags |
3814 |
6.3.21 |
Unsigned32 |
M, V |
No |
|||
|
ProSe-Validity-Timer |
3815 |
6.3.22 |
Unsigned32 |
M, V |
No |
|||
|
Requesting-EPUID |
3816 |
6.3.23 |
UTF8String |
M, V |
No |
|||
|
Targeted-EPUID |
3817 |
6.3.26 |
UTF8String |
M, V |
No |
|||
|
Time-Window |
3818 |
6.3.27 |
Unsigned32 |
M, V |
No |
|||
|
WiFi-P2P-Assistance-Info |
3819 |
6.3.30 |
Grouped |
M, V |
No |
|||
|
WLAN-Assistance-Info |
3820 |
6.3.31 |
Grouped |
M, V |
No |
|||
|
WLAN-Link-Layer-Id |
3821 |
6.3.32 |
OctetString |
M, V |
No |
|||
|
WLAN-Link-Layer-Id-List |
3822 |
6.3.33 |
Grouped |
M, V |
No |
|||
|
Location-Update-Trigger |
3823 |
6.3.42 |
Grouped |
M,V |
No |
|||
|
Location-Update-Event-Type |
3824 |
6.3.43 |
Unsigned32 |
M,V |
No |
|||
|
Change-Of-Area-Type |
3825 |
6.3.44 |
Grouped |
M,V |
No |
|||
|
Location-Update-Event-Trigger |
3826 |
6.3.45 |
Unsigned32 |
M,V |
No |
|||
|
Report-Cardinality |
3827 |
6.3.46 |
Enumerated |
M,V |
No |
|||
|
Minimum-Interval-Time |
3828 |
6.3.47 |
Unsigned32 |
M,V |
No |
|||
|
Periodic-Location-Type |
3829 |
6.3.48 |
Grouped |
M,V |
No |
|||
|
Location-Report-Interval-Time |
3830 |
6.3.49 |
Unsigned32 |
M,V |
No |
|||
|
Total-Number-Of-Reports |
3831 |
6.3.50 |
Unsigned32 |
M,V |
No |
|||
|
Validity-Time-Announce |
3832 |
6.3.36 |
Unsigned32 |
M, V |
No |
|||
|
Validity-Time-Monitor |
3833 |
6.3.37 |
Unsigned32 |
M, V |
No |
|||
|
Validity-Time-Communication |
3834 |
6.3.38 |
Unsigned32 |
M, V |
No |
|||
|
ProSe-App-Code-Info |
3835 |
6.3.39 |
Grouped |
M. V |
No |
|||
|
MIC |
3836 |
6.3.40 |
OctetString |
M, V |
No |
|||
|
UTC-based-Counter |
3837 |
6.3.41 |
Unsigned32 |
M. V |
No |
|||
|
ProSe-Match-Refresh-Timer |
3838 |
6.3.52 |
Unsigned32 |
M, V |
No |
|||
|
ProSe-Metadata-Index-Mask |
3839 |
6.3.60 |
OctetString |
V |
M |
No |
||
|
App-Identifier |
3840 |
6.3.61 |
Group |
V |
M |
No |
||
|
OS-ID |
3841 |
6.3.62 |
OctetString |
V |
M |
No |
||
|
OS-App-ID |
3842 |
6.3.63 |
UTF8String |
V |
M |
No |
||
|
Requesting-RPAUID |
3843 |
6.3.64 |
UTF8String |
V |
M |
No |
||
|
Target-RPAUID |
3844 |
6.3.65 |
UTF8String |
V |
M |
No |
||
|
Target-PDUID |
3845 |
6.3.66 |
OctetString |
V |
M |
No |
||
|
ProSe-Restricted-Code |
3846 |
6.3.67 |
OctetString |
V |
M |
No |
||
|
ProSe-Restricted-Code-Suffix-Range |
3847 |
6.3.68 |
OctetString |
V |
M |
No |
||
|
Beginning-Suffix |
3848 |
6.3.69 |
OctetString |
V |
M |
No |
||
|
Ending-Suffix |
3849 |
6.3.70 |
OctetString |
V |
M |
No |
||
|
Discovery-Entry-ID |
3850 |
6.3.59 |
Unsigned32 |
V |
M |
No |
||
|
Match-Timestamp |
3851 |
6.3.71 |
Time |
V |
M |
No |
||
|
PMR-Flags |
3852 |
6.3.57 |
Unsigned32 |
M,V |
No |
|||
|
ProSe-Application-Metadata |
3853 |
6.3.58 |
UTF8String |
M,V |
No |
|||
|
Discovery-Auth-Request |
3854 |
6.3.53 |
Grouped |
M, V |
No |
|||
|
Discovery-Auth-Response |
3855 |
6.3.54 |
Grouped |
M, V |
No |
|||
|
Match-Request |
3856 |
6.3.55 |
Grouped |
M, V |
No |
|||
|
Match-Report-Info |
3857 |
6.3.56 |
Grouped |
M, V |
No |
|||
|
Banned-RPAUID |
3858 |
6.3.73 |
UTF8String |
V |
M |
No |
||
|
Banned-PDUID |
3859 |
6.3.74 |
OctetString |
V |
M |
No |
||
|
Code-Receiving-Security-Material |
3860 |
6.3.75 |
Grouped |
V |
M |
No |
||
|
Code-Sending-Security-Material |
3861 |
6.3.76 |
Grouped |
V |
M |
No |
||
|
DUSK |
3862 |
6.3.77 |
OctetString |
V |
M |
No |
||
|
DUIK |
3863 |
6.3.78 |
OctetString |
V |
M |
No |
||
|
DUCK |
3864 |
6.3.79 |
OctetString |
V |
M |
No |
||
|
MIC-Check-indicator |
3865 |
6.3.80 |
Unsigned32 |
V |
M |
No |
||
|
Encrypted-Bitmask |
3866 |
6.3.81 |
OctetString |
V |
M |
No |
||
|
ProSe-App-Code-Suffix-Range |
3867 |
6.3.82 |
OctetString |
V |
M |
No |
||
|
PC5-tech |
3868 |
6.3.84 |
OctetString |
V |
M |
No |
||
|
NOTE 1: The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header bit denoted as "V" indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [29]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
||||||||
The following table (table 6.3.1-2) specifies the Diameter AVPs re-used by the PC6/PC7 interfaces from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within PC6/PC7 interfaces.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol, do not need to be supported. The AVPs from Diameter Base Protocol are not included in table 6.3.1-2.
Table 6.3.1-2: PC6/PC7 re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
M-bit |
|---|---|---|---|
|
Supported-Features |
3GPP TS 29.229 [10] |
||
|
EAP-Master-Session-Key |
IETF RFC 4072 [12] |
||
|
Feature-List-ID |
3GPP TS 29.229 [10] |
||
|
Feature-List |
3GPP TS 29.229 [10] |
See clause 7.3.10 |
|
|
MSISDN |
3GPP TS 29.329 [5] |
||
|
User-Name |
IETF RFC 6733 [29] |
||
|
Location-Estimate |
3GPP TS 32.299 [13] |
||
|
ProSe-Direct-Allowed |
3GPP TS 29.344 [14] |
||
|
Authorized-Discovery-Range |
3GPP TS 29.344 [14] |
||
|
SSID |
3GPP TS 29.273 [15] |
||
|
Visited-PLMN-Id |
3GPP TS 29.272 [16] |
||
|
User-Identifier |
3GPP TS 29.336 [18] |
||
|
OC-Supported-Features |
IETF RFC 7683 [21] |
See clause 6.3.34 |
Must set |
|
OC-OLR |
IETF RFC 7683 [21] |
See clause 6.3.35 |
Must set |
|
DRMP |
IETF RFC 7944 [27] |
see clause 6.3.72 |
Must not set |
|
Service-Result |
3GPP TS 29.336 [18] |
||
|
Load |
IETF RFC 8583 [28] |
See clause 6.3.83 |
Must not set |
|
NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
|||
6.3.2 App-Layer-User-Id
The App-Layer-User-Id AVP is of type UTF8String. This AVP contains an identity identifying a user within the context of a specific application (e.g. alice@social.net).
6.3.3 Assistance-info
The Assistance-Info AVP is of type Grouped. It shall contain the information for direct discovery and communications between UEs.
The AVP format shall conform to:
Assistance-Info ::= <AVP header: 3802 10415>
[ WLAN-Assistance-Info ]
*[AVP]
6.3.4 Assistance-Info-Validity-Timer
The Assistance-Info-Validity-Timer AVP is of type Unsigned32 and it shall contain the maximum number of seconds of validity of the provided assistance information.
6.3.5 Discovery-Type
The Discovery-Type AVP is of type Unsigned32 and contains a 32-bit address space representing types of Direct Discovery Authorization Request. The following values are defined:
ANNOUNCING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY (0)
This value is used when the Direct Discovery Authorization Request message is sent for a UE requesting authorization for announcing in open Prose Direct Discovery (Model A).
MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY (1)
This value is used when the Direct Discovery Authorization Request message is sent for a UE requesting authorization for monitoring in open Prose Direct Discovery (Model A).
ANNOUNCING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (2)
This value is used when the Direct Discovery Authorization Request message is sent for a UE requesting authorization for announcing in restricted ProSe Direct Discovery (Model A).
MONITORING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (3)
This value is used when the Direct Discovery Authorization Request message is sent for a UE requesting authorization for monitoring in restricted ProSe Direct Discovery (Model A).
DISCOVEREE_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (4)
This value is used when the Direct Discovery Authorization Request message is sent for a discoveree UE requesting authorization for monitoring in restricted ProSe Direct Discovery (Model B).
DISCOVERER_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (5)
This value is used when the Direct Discovery Authorization Request message is sent to the ProSe Function in local PLMN for a discoverer UE requesting authorization for announcing in restricted ProSe Direct Discovery (Model B).
DISCOVERER_ANNOUNCING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (6)
This value is used when the Direct Discovery Authorization Request message is sent to the ProSe Function in the visited PLMN for a discoverer UE requesting authorization for announcing in restricted ProSe Direct Discovery (Model B).
MONITORING_UPDATE_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (7)
This value is used when the Direct Discovery Authorization Request message is sent for the ProSe Function requesting to ban a user of an authorization for monitoring in restricted ProSe Direct Discovery (Model A).
MONITORING_RESPONSE_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY (8)
This value is used when the Direct Discovery Authorization Request message is sent for the ProSe Function reporting the result of an authorization for monitoring in restricted ProSe Direct Discovery (Model A).
6.3.6 EAP-Master-Session-Key
The EAP-Master-Session-Key AVP is of type OctetString and it shall contains keying material for protecting the communications between UEs. This AVP is defined in the IETF RFC 4072 [12]
6.3.7 Feature-List-ID AVP
The syntax of this AVP is defined in 3GPP TS 29.229 [10]. For this release, the Feature-List-ID AVP value shall be set to 1.
6.3.8 Feature-List AVP
The syntax of this AVP is defined in 3GPP TS 29.229 [10]. A null value indicates that there is no feature used by the application.
NOTE: There is no feature defined for this release.
6.3.9 Filter-Id
The Filter-Id AVP is of type OctectString. This AVP shall contain the identifier of a Discovery Filter.
6.3.10 Location-Estimate
The Location-Estimate AVP is of type OctetString and it shall contain an estimate of the location of an MS in universal coordinates and the accuracy of the estimate. This AVP is defined in the 3GPP TS 32.299 [13].
6.3.11 MAC-Address
The MAC-Address AVP is of type UTF8String and it shall contain a 6-octet MAC address used as link layer identifier for discovery and communication. It shall be encoded in upper-case ASCII characters with the octet values separated by dash characters. It shall contain a string of 17 octets. Example: "00-10-A4-23-19-C0".
6.3.12 Match-Report
The Match-Report AVP is of type Grouped. It shall contain the information elements used in ProSe Match Report answer.
The AVP format shall conform to:
Match-Report ::= <AVP header: 3807 10415>
{ Discovery-Type }
[ ProSe-App-Code ]
[ ProSe-Metadata-Index-Mask ]
[ ProSe-App-Id ]
[ ProSe-Validity-Timer ]
[ ProSe-Match-Refresh-Timer ]
[ ProSe-Application-Metadata ]
[ PC5-tech ]
*[AVP]
The valid value for Discovery-Type for Match-Report AVP is: "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY",
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Match-Report shall contain a ProSe Application Code, the associated ProSe Application ID Name, the validity time for which the ProSe Application Code is valid, the associated match report refresh timer and optionally the PC5 radio technology that the UE is using.
If the ProSe Application Code contains a metadata index, a ProSe-Metadata-Index-Mask AVP shall be provided for this ProSe Application Code.
6.3.13 MSISDN
The MSISDN AVP is of type OctetString. This AVP contains an MSISDN, in international number format as described in ITU-T Rec E.164 [19]. This AVP is defined in the 3GPP TS 29.329 [5].
6.3.14 Operating-Channel
The Operating-Channel AVP is of type Unsigned32 and it shall contain the operating channel in MHz on which Wi-Fi P2P discovery and communication should take place.
6.3.15 P2P-Features
The P2P-Features AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.15-1:
Table 6.3.15-1: P2P-Features
|
Bit |
Name |
Description |
|
0 |
Group Owner Indication |
This bit, when set, shall indicate that the UE should implement the Group Owner (GO) functionality specified in the Wi-Fi P2P specification [17]. When not set, this bit shall indicate the UE should behave as a Wi-Fi P2P client that attempts to discover and associate with a GO. |
|
NOTE: Bits not defined in this table shall be cleared by the sending ProSe Function and discarded by the receiving ProSe Function. |
||
6.3.16 ProSe-App-Code
The ProSe-App-Code AVP is of type OctetString. This AVP contains a ProSe Application Code or ProSe Application Code Prefix (see 3GPP TS 23.003 [4]) is associated with a ProSe Application ID.
6.3.17 ProSe-App-Id
The ProSe-App-Id AVP is of type UTF8String. This AVP contains a ProSe Application ID (see 3GPP TS 23.003 [4]).
6.3.18 ProSe-App-Mask
The ProSe-App-Mask AVP is of type OctetString. This AVP contains a ProSe Application Mask (see 3GPP TS 24.334 [22]).
6.3.19 ProSe-Direct-Allowed
The ProSe-Direct-Allowed AVP is of type Unsigned32 and it shall contain a bit mask that indicates the permissions for ProSe direct services for the UE in the PLMN of the responding ProSe Function. This AVP is defined in the 3GPP TS 29.344 [14].
6.3.20 ProSe-Discovery-Filter
The ProSe-Discovery-Filter AVP is of type Grouped. It shall contain a Filter ID, a ProSe Application ID name, a validity timer, a ProSe Application Code and zero or more ProSe Application Masks.
The AVP format shall conform to:
ProSe-Discovery-Filter ::= <AVP header: 3813 10415>
{ Filter-Id }
{ ProSe-App-Id }
{ ProSe-Validity-Timer }
{ ProSe-App-Code }
*[ ProSe-App-Mask ]
*[AVP]
6.3.21 PRR-Flags
The PRR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.21-1:
Table 6.3.21-1: PRA-Flags
|
Bit |
Name |
Description |
|
0 |
WLAN Indication |
This bit, when set, shall indicate the UE is requested EPC support for WLAN direct discovery and communication |
|
NOTE: Bits not defined in this table shall be cleared by the sending ProSe Function and discarded by the receiving ProSe Function. |
||
6.3.22 ProSe-Validity-Timer
The ProSe-Validity-Timer AVP is of type Unsigned32 and it shall contain the maximum number of seconds of validity of a ProSe Application Code or a ProSe Discovery Filter.
6.3.23 Requesting-EPUID
The Requesting-EPUID AVP is of type UTF8String. This AVP contains an identifier for EPC-level ProSe Discovery and EPC support for WLAN direct communication that uniquely identifies a UE registered for ProSe triggering a Proximity request.
6.3.24 Supported-Features
The Supported-Features AVP is of type Grouped and it informs the destination host about the features that the origin host supports for the application. This AVP is defined in the 3GPP TS 29.229 [10].
6.3.25 SSID
The SSID AVP is of type UTF8String and it shall contain the Service Set Identifier which identifies a specific 802.11 extended service set (see IEEE Std 802.11-2012 [20]). This AVP is defined in the 3GPP TS 29.273 [15].
6.3.26 Targeted-EPUID
The Targeted-EPUID AVP is of type UTF8String. This AVP contains an identifier for EPC-level ProSe Discovery and EPC support for WLAN direct communication that uniquely identifies a UE registered for ProSe targeted by a Proximity request.
6.3.27 Time-Window
The Time-Window AVP is of type Unsigned32 and it shall contain the maximum number of seconds of validity of the Proximity request.
6.3.28 User-Identifier
The User-Identifier AVP is of type Grouped. It shall contain the UE identity used as identifier of a Proximity-based service subscribed by the user (i.e. IMSI or MSISDN). This AVP is defined in the 3GPP TS 29.336 [18].
6.3.29 Visited-PLMN-Id
The Visited-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. This AVP is defined in the 3GPP TS 29.272 [16].
6.3.30 WiFi-P2P-Assistance-Info
The WiFi-P2P-Assistance-Info AVP is of type Grouped. It shall contain information to assist WLAN direct discovery and communication as required by the Wi-Fi P2P technology.
The AVP format shall conform to:
WiFi-P2P-Assistance-Info ::= <AVP header: 3819 10415>
[ SSID ]
[ EAP-Master-Session-Key ]
[ P2P-Features ]
[ WLAN-Link-Layer-Id-List ]
[ WLAN-Link-Layer-Id-List ]
[ Operating-Channel ]
[ Assistance-Info-Validity-Timer ]
*[AVP]
6.3.31 WLAN-Assistance-Info
The WLAN-Assistance-Info AVP is of type Grouped. It shall contain information to assist WLAN direct discovery and communication required for WLAN direct discovery and communication between UEs.
The AVP format shall conform to:
WLAN-Assistance-Info ::= <AVP header: 3820 10415>
[ WiFi-P2P-Assistance-Iinfo ]
*[AVP]
6.3.32 WLAN-Link-Layer-Id
The WLAN-Link-Layer-Id AVP is of type Grouped. It shall contain a link layer identity used for WLAN direct discovery and/or WLAN direct communication.
The AVP format shall conform to:
WLAN-Link-Layer-Id ::= <AVP header: 3821 10415>
[ MAC-Address ]
*AVP
6.3.33 WLAN-Link-Layer-Id-List
The WLAN-Link-Layer-Id-List AVP is of type Grouped. It shall contain a list of WLAN Link Layer IDs provided to a UE implementing the Group Owner functionality in a Wi-Fi P2P group.
The AVP format shall conform to:
WLAN-Link-Layer-Id-List ::= <AVP header: 3822 10415>
*[ WLAN-Link-Layer-Id ]
*AVP
6.3.34 OC-Supported-Features
The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683 [21]. This AVP is used to support Diameter overload control mechanism, see Annex A for more information.
6.3.35 OC-OLR
The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683 [21]. This AVP is used to support Diameter overload control mechanism, see Annex A for more information.
6.3.36 Validity-Time-Announce
The Validity-Time-Announce AVP is of type Unsigned32 and it shall contain the maximum number of seconds of validity of a ProSe announcing authorization policy.
6.3.37 Validity-Time-Monitor
The Validity-Time-Monitor AVP is of type Unsigned32 and it shall contain the maximum number of seconds of validity of a ProSe monitoring authorization policy.
6.3.38 Validity-Time-Communication
The Validity-Time-Communication AVP is of type Unsigned32 and it shall contain the maximum number of seconds of validity of a ProSe communication authorization policy.
6.3.39 ProSe-App-Code-Info
The ProSe-App-Code-Info AVP is of type Grouped. It shall contain a ProSe Application Code, the associated MIC and the associated UTC-based counter.
The AVP format shall conform to:
ProSe-App-Code-Info ::= <AVP header: 3835 10415>
{ ProSe-App-Code }
{ MIC }
{ UTC-based-Counter }
*[AVP]
6.3.40 MIC
The MIC AVP is of type OctetString and shall contain a MIC (Message Integrity Check) associated with a discovered ProSe Application Code, as defined in 3GPP TS 33.303 [23].
6.3.41 UTC-based-Counter
The UTC-based-Counter AVP is of type Unsigned32 and it shall contain the UTC-based counter (in seconds) associated with a discovered ProSe Application Code as defined in 3GPP TS 24.334 [22].
6.3.42 Location-Update-Trigger
The Location-Update-Trigger AVP is of type Grouped. It shall contain the type of event that will trigger a locate update procedure to forward the location of UE to the ProSe Function initiating the Proximity Request.
The AVP format shall conform to:
Location-Update-Trigger::= <AVP header: 3823 10415>
{ Location-Update-Event-Type }
[ Change-Of-Area-Type ]
[ Periodic-Location-Type ]
*[AVP]
The Change-Of-Area-Type AVP shall be present if the Location-Update-Event-Type AVP value is set to CHANGE_OR_AREA (1). Otherwise, it shall be absent.
The Periodic-Location-Type AVP shall be present if the Location-Update-Event-Type AVP value is set to PERIODIC_LOCATION (2). Otherwise, it shall be absent.
6.3.43 Location-Update-Event-Type
The Location-Update-Event-Type AVP is of type Unsigned32 and contains an 32-bit address space representing types of events that will trigger a location update. The following values are defined:
UE_AVAILABLE (0)
This value shall be used to indicate that the location update trigger is any event in which the MSC/SGSN/MME has established a contact with the UE.
CHANGE_OF_AREA (1)
This value shall be used to indicate that the location update trigger is an event where the UE enters or leaves a pre-defined geographical area or if the UE is currently within the pre-defined geographical area.
PERIODIC_LOCATION (2)
This value shall be used to indicate that the location update trigger is an event where a defined periodic timer expires in the UE and activates a location report or a location request
The types of event listed above are defined in the clause 4.4.2.1 of the 3GPP TS 23.271 [24]
6.3.44 Change-Of-Area-Type
The Change-Of-Area-Type AVP is of type Grouped. It shall contain the information related to the type of event that will trigger a locate update procedure to forward the location of UE to the ProSe Function initiating the Proximity Request.
The AVP format shall conform to:
Change-Of-Area-Type::= <AVP header: 3825 10415>
{ Location-Update-Event-Trigger }
{ Report-Cardinality }
[ Minimum-Interval-Time ]
*[AVP]
The Minimum-Interval-Time AVP may be present only if the Report-Cardinality AVP value is set to MULTIPLE (1).
6.3.45 Location-Update-Event-Trigger
The Location-Update-Event-Type AVP is of type Unsigned32 and contains a 32-bit address space representing the possible change of area events i.e. UE enters, leaves or is within requested target area. The following values are defined:
UE_ENTRY (0)
This value shall be used to indicate the event trigger is the UE entering a pre-defined geographical area.
UE_EXIT (1)
This value shall be used to indicate the event trigger is the UE leaving a pre-defined geographical area
UE_PRESENCE (2)
This value shall be used to indicate the event trigger is the current presence of the UE within a pre-defined geographical area.
The types of change of area event listed above are defined in the clause 4.4.2.1 of the 3GPP TS 23.271 [24].
6.3.46 Report-Cardinality
The Report-Cardinality AVP is of type Enumerated. The following values are defined:
SINGLE (0)
This value shall be used to indicate the change of area event shall be reported one time only.
MULTIPLE (1)
This value shall be used to indicate the change of area event may be reported several times.
6.3.47 Minimum-Interval-Time
The Minimum-Interval-Time AVP is of type Unsigned32 and shall contain the minimum number of seconds between area event reports.
6.3.48 Periodic-Location-Type
The Periodic-Location-Type AVP is of type Grouped. It shall contain the time interval between successive location reports and the total number of reports.
The AVP format shall conform to:
Periodic-Location-Type::= <AVP header: 3829 10415>
{ Location-Report-Interval-Time }
{ Total-Number-Of-Reports }
*[AVP]
6.3.49 Location-Report-Interval-Time
The Location-Report-Interval-Time AVP is of type Unsigned32 and shall contain the number of seconds between successive location reports.
6.3.50 Total-Number-Of-Reports
The Total-Number-Of-Reports AVP is of type Unsigned32 and shall indicate the maximum number of requested location reports.
6.3.51 Authorized-Discovery-Range
The Authorized-Discovery-Range AVP is of type Unsigned32 and it shall contain a value that indicates the authorised announcing range (short/medium/long) at which the UE is allowed to announce in the given PLMN according to the defined announcing authorisation policy for this UE. This AVP is defined in the 3GPP TS 29.344 [14].
6.3.52 ProSe-Match-Refresh-Timer
The ProSe-Match-Refresh-Timer AVP is of type Unsigned32 and it shall contain the number of seconds indicating how long the UE shall wait before sending a new Match Report for the associated ProSe Application Code.
6.3.53 Discovery-Auth-Request
The Discovery-Auth-Request is of type Grouped. It shall contain the information elements used in ProSe direct discovery authorization request.
The AVP format shall conform to:
Discovery-Auth-Request ::= <AVP header: 3854 10415>
{ Discovery-Type }
[ User-Identity ]
[ ProSe-App-ID ]
[ ProSe-App-Code ]
[ ProSe-App-Code-Suffix-Range ]
[ ProSe-Validity-Timer ]
[ App-Identifier ]
[ Requesting-RPAUID ]
[ Target-RPAUID ]
[ Target-PDUID ]
[ ProSe-Restricted-Code ]
[ ProSe-Query-Code ]
[ ProSe-Response-Code ]
*[ ProSe-Restricted-Code-Suffix-Range ]
[ Banned-RPAUID ]
[ Banned-PDUID ]
[ Service-Result ]
[ PC5-tech ]
*[AVP]
When the Discovery-Type is set to "ANNOUNCING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, a ProSe Application ID, a ProSe Application Code and optionally one or more ProSe Restricted Code Suffix-Range, ProSe Validity Timer and the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, a ProSe Application ID and optionally the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "ANNOUNCING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, an Application Identifier, the Requesting RPAUID, ProSe Restricted Code and optionally one or more ProSe Restricted Code SuffixRange, a ProSe Validity Timer and the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, an Application Identifier, Requesting RPAUID, Target RPAUID, Target PDUID and optionally the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "DISCOVEREE_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, an Application Identifier, Requesting RPAUID, a ProSe Response Code and optionally the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "DISCOVERER_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, an Application Identifier, Requesting RPAUID, Target RPAUID, Target PDUID and optionally the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "DISCOVERER_ANNOUNCING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain a UE identity, an Application Identifier, Requesting RPAUID, a ProSe Query Code and optionally the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "MONITORING_UPDATE_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain an Application Identifier, a ProSe Restricted Code, a Banned RPAUID, a Banned PDUID and optionally the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "MONITORING_RESPONSE_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Request shall contain an Application Identifier, ProSe-Restricted-Code, Banned RPAUID, Banned PDUID, Result and optionally the PC5 radio technology that the UE is using.
6.3.54 Discovery-Auth-Response
The Discovery-Auth-Response is of type Grouped. It shall contain the information elements used in ProSe direct discovery authorization answer.
The AVP format shall conform to:
Discovery-Auth-Response ::= <AVP header: 3855 10415>
{ Discovery-Type }
*[ ProSe-Discovery-Filter ]
[ Visited-PLMN-Id ]
[ ProSe-Restricted-Code ]
[ ProSe-Query-Code ]
[ ProSe-Response-Code ]
[ ProSe-Validity Timer ]
[ Code-Sending-Security-Material ]
[ Code-Receiving-Security-Material ]
[ DUIK ]
[ PC5-tech ]
*[AVP]
When the Discovery-Type is set to "ANNOUNCING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Response shall contain no other parameters.
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Response shall contain one or more ProSe Discovery Filters, optionally a PLMN ID and the PC5 radio technology that the UE is using.
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Response shall contain a ProSe Restricted Code, a Code Receiving Security Material, optionally a DUIK, a ProSe Validity Timer and the PC5 radio technology that the UE is using. The DUIK parameter shall be included in Discovery-Auth-Response only if the Code-Receiving-Security-Material contains a MIC Check Indicator set to MIC_CHECK_BY_PROSE_FUNCTION.
When the Discovery-Type is set to "DISCOVERER_REQUEST_FOR_RESTRICTED_PROSE_DIRECT_DISCOVERY", the Discovery-Auth-Response shall contain a ProSe Query Code, a Code Sending Security Material, a ProSe Response Code, a Code Receiving Security Material, optionally a DUIK, a ProSe Validity Timer and the PC5 radio technology that the UE is using. The DUIK parameter shall be included in Discovery-Auth-Response only if the Code-Receiving-Security-Material contains a MIC Check Indicator set to MIC_CHECK_BY_PROSE_FUNCTION.
6.3.55 Match-Request
The Match-Request is of type Grouped. It shall contain the information elements used in ProSe Match Report request.
The AVP format shall conform to:
Match-Request ::= <AVP header: 3856 10415>
{ Discovery-Type }
[ User Identity ]
[ Visited-PLMN-ID ]
*[ ProSe-App-Code-Info ]
[ PC5-tech ]
*[AVP]
The valid value for Discovery-Type for Match-Report AVP is: "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY",
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Match-Request shall contain one UE Identity, one Visited PLMN ID, one or more ProSe App Code Info and optionally the PC5 radio technology that the UE is using.
6.3.56 Match-Report-Info
The Match-Report-Info is of type Grouped. It shall contain the information elements used in ProSe Match Report Info request.
The AVP format shall conform to:
Match-Report-Info ::= <AVP header: 3857 10415>
{ Discovery-Type }
[ User-Identity ]
*[ ProSe-App-ID ]
*[AVP]
The valid value for Discovery-Type for Match-Report-Info AVP is: "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY",
When the Discovery-Type is set to "MONITORING_REQUEST_FOR_OPEN_PROSE_DIRECT_DISCOVERY", the Match-Report-Info shall contain one User Identity and one or more ProSe Application IDs.
6.3.57 PMR-Flags
The PMR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.57/1:
Table 6.3.57/1: PMR-Flags
|
Bit |
Name |
Description |
|
0 |
Metadata Requested |
This bit, when set, indicates that metadata information associated with the ProSe Application ID are requested. |
|
NOTE: Bits not defined in this table shall be cleared by the sending Prose Function and discarded by the receiving receiving ProSe function. |
||
6.3.58 ProSe-Application-Metadata
The ProSe-Application-Metadata AVP is of type UTF8String. This AVP shall contain the metadata associated with the ProSe Application ID contained in the Match Report. As defined in 3GPP TS 24.334 [22], the length and contents of the metadata formatted as UTF8-encoded string are out of scope of 3GPP.
6.3.59 Discovery-Entry-ID
The Discovery-Entry-ID is of type Unsigned32. It shall contain the discovery Entry ID used to identify the discovery entry in the UE context related to the discovery authorization request in the requesting ProSe Function.
6.3.60 ProSe-Metadata-Index-Mask
The ProSe-Metadata-Index-Mask AVP is of type OctetString. This AVP contains a ProSe metadata index mask (see 3GPP TS 24.334 [22]).
6.3.61 App-Identifier
The App-Identifier AVP is of type Grouped. It shall contain an OS ID and OS Application ID name.
The AVP format shall conform to:
App-Identifier ::= <AVP header: 3840 10415>
{ OS-ID }
{ OS-App-ID }
*[AVP]
6.3.62 OS-ID
The OS-ID AVP is of type OctetString. It shall contain an identifier of the operating system as defined in clause 12.2.2.5 in 3GPP TS 24.334 [22].
6.3.63 OS-App-ID
The OS-App-ID AVP is of type UTF8String. It shall contain an OS specific application as defined in clause 12.2.2.5 in 3GPP TS 24.334 [22].
6.3.64 Requesting-RPAUID
The Requesting-RPAUID AVP is of type UTF8String. This AVP contains an identifier for restricted ProSe direct discovery that uniquely identifies an application user originating a restricted ProSe direct discovery request.
6.3.65 Target-RPAUID
The Target-RPAUID AVP is of type UTF8String. This AVP contains an identifier for restricted ProSe direct discovery that uniquely identifies an application user targeted by a restricted ProSe direct discovery request.
6.3.66 Target-PDUID
The Target-PDUID AVP is of type OctetString. It shall contain the ProSe Discovery UE ID which uniquely identifies the UE targeted by a restricted ProSe direct discovery request.
6.3.67 ProSe-Restricted-Code
The ProSe-Restricted-Code AVP is of type OctetString. This AVP contains a ProSe Restricted Code (see 3GPP TS 23.003 [4]) which is associated with a RPAUID.
6.3.68 ProSe-Restricted-Code-Suffix-Range
The ProSe-Restricted-Code-Suffix-Range AVP is of type Grouped. It contains a range of consecutive ProSe Restricted Code Suffixes that can be appended to a ProSe Restricted Code Prefix. It shall contain a Beginning Suffix and may contain an Ending Suffix. If the Ending Suffix is not present, the only ProSe Restricted Code Suffix included in the ProSe Restricted Code Suffix Range is equal to the Beginning Suffix.
The AVP format shall conform to:
ProSe-Restricted-Code-Suffix-Range ::= <AVP header: 3847 10415>
{ Beginning-Suffix}
[ Ending–Suffix ]
*[AVP]
Beginning Sufifx and Ending Suffix shall have the same length.
6.3.69 Beginning-Suffix
The Beginning-Suffix AVP is of type OctetString. This AVP shall contain the lowest ProSe Restricted Code Suffix in a consecutive sequence of ProSe Restricted Code suffixes, or the lowest ProSe Application Code Suffix in a consecutive sequence of ProSe Application Code Suffixes. The format of ProSe Restricted Code Suffix or ProSe Application Code Suffix is defined in 3GPP TS 23.003 [4]. The size of this suffix shall align with octet boundary.
6.3.70 Ending-Suffix
The Ending-Suffix AVP is of type OctetString. This AVP shall contain the highest ProSe Restricted Code Suffix in a consecutive sequence of ProSe Restricted Code suffixes or the highest ProSe Application Code Suffix in a consecutive sequence of ProSe Application Code Suffixes. The format of ProSe Restricted Code Suffix or ProSe Application Code Suffix is defined in 3GPP TS 23.003 [4]. The size of this suffix shall align with octet boundary.
6.3.71 Match-Timestamp
The Match-Timestamp AVP is of type Time and it shall contain the UTC time identifying when the discovery match event occurred.
6.3.72 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [27]. This AVP allows the Prose Function to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message.
6.3.73 Banned-RPAUID
The Banned-RPAUID AVP is of type UTF8String. This AVP contains an identifier for restricted ProSe direct discovery that uniquely identifies an application user banned by a restricted ProSe direct discovery request.
6.3.74 Banned-PDUID
The Banned-PDUID AVP is of type OctetString. It shall contain the ProSe Discovery UE ID which uniquely identifies the UE Banned by a restricted ProSe direct discovery request.
6.3.75 Code-Receiving-Security-Material
The Code-Receiving-Security-Material AVP is of type Grouped. It shall contain security parameters used to indicate to a UE how a received restricted ProSe direct discovery message is protected. The Code Receiving Security Material may contain a DUSK and may contain either a DUIK or an indication whether to use Match Reports for MIC checking. It may also contain both a DUCK and a corresponding Encrypted Bitmask.
The AVP format shall conform to:
Code-Receiving-Security-Material ::= <AVP header: 3847 10415>
[ DUSK ]
[ DUIK ]
[ MIC-Check-Indicator ]
[ DUCK ]
[ Encrypted-Bitmask ]
*[AVP]
6.3.76 Code-Sending-Security-Material
The Code-Sending-Security-Material AVP is of type Grouped. It shall contain security parameters used to indicate to a UE how to protect the transmission of restricted ProSe direct discovery message. The Code Sending Security Material may contain a DUSK and may contain a DUIK. It may also contain both a DUCK and a corresponding Encrypted Bitmask.
The AVP format shall conform to:
Code-Sending-Security-Material ::= <AVP header: 3847 10415>
[ DUSK ]
[ DUIK ]
[ DUCK ]
[ Encrypted-Bitmask ]
*[AVP]
6.3.77 DUSK
The DUSK AVP is of type OctetString. It shall contain the Discovery User Scrambling Key used to scramble or unscramble the restricted ProSe direct discovery message containing the ProSe Restricted Code, ProSe Query Code or ProSe Response Code. The format of the DUSK is defined in 3GPP TS 33.303 [23].
6.3.78 DUIK
The DUIK AVP is of type OctetString. It shall contain the Discovery User Integrity Key used to compute the MIC of the restricted ProSe direct discovery message containing the ProSe Restricted Code, ProSe Query Code or ProSe Response Code. The format of the DUIK is defined in 3GPP TS 33.303 [23].
6.3.79 DUCK
The DUCK AVP is of type OctetString. It shall contain the Discovery User Confidentiality Key used to encrypt and decrypt a portion in restricted ProSe direct discovery message.The format of the DUCK is defined in 3GPP TS 33.303 [23].
6.3.80 MIC-Check-Indicator
The MIC-Check-Indicator AVP is of type Unsigned32. It shall contain the indication of whether the UE shall use the ProSe Function to verify the MIC field of the received discovery message. The following values are defined:
MIC_CHECK_BY_PROSE_FUNCTION (1)
This value is used when the MIC check is required to be done by the ProSe Function.
6.3.81 Encrypted-Bitmask
The Encrypted-Bitmask AVP is of type OctetString. It shall contain a 184-bit bitmask which uses bit "1" to mark the positions of the bits of a ProSe Restricted Code, ProSe Query Code or ProSe Response Code, for which the DUCK encryption is applied.
6.3.82 ProSe-App-Code-Suffix-Range
The ProSe-App-Code-Suffix-Range AVP is of type Grouped. It contains a range of consecutive ProSe Application Code Suffixes that can be appended to a ProSe Application Code Prefix. It shall contain a Beginning Suffix and may contain an Ending Suffix. If the Ending Suffix is not present, the only ProSe Application Code Suffix included in the ProSe Application Code Suffix Range is equal to the Beginning Suffix.
The AVP format shall conform to:
ProSe-App-Code-Suffix-Range ::= <AVP header: 3847 10415>
{ Beginning-Suffix }
[ Ending–Suffix ]
*[AVP]
Beginning Suffix and Ending Suffix shall have the same length.
6.3.83 Load
The Load AVP is of type Grouped and it is defined in IETF RFC 8583 [28]. This AVP is used to support Diameter load control mechanism, see Annex D for more information.
6.3.84 PC5-tech
The PC5-tech AVP is of type OctetString. It shall contain an identifier of the PC5 radio technology as defined in clause 12.2.2.71 in 3GPP TS 24.334 [22].
6.4 Result-Code and Experimental-Result Values
6.4.1 General
This clause defines result code values that shall be supported by all Diameter implementations that conform to this specification.
6.4.2 Success
Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully completed. The Result-Code AVP values defined in the Diameter base protocol (IETF RFC 6733 [29]) shall be applied.
6.4.3 Permanent Failures
Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and should not be attempted again. The Result-Code AVP values defined in the Diameter base protocol (IETF RFC 6733 [29]) shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent.
6.4.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001)
This result code shall be sent by the ProSe Function in the HPLMN to indicate that the user identified by the UE identity is unknown
6.4.3.2 DIAMETER_ERROR_UNAUTHORIZED_SERVICE (5511)
This result code shall be sent by the ProSe Function in the HPLMN to indicate that no ProSe subscription is associated with the UE.
6.4.3.3 DIAMETER_ERROR_NO_ASSOCIATED_DISCOVERY_FILTER (5630)
This result code shall be sent by the ProSe Function in the local/visited PLMN to indicate that there is no valid Discovery Filter associated to the ProSe Application ID name received in the request.
6.4.3.4 DIAMETER_ERROR_ANNOUNCING_UNAUTHORIZED_IN_PLMN (5631)
This result code shall be sent by the ProSe Function in the local/visited PLMN to indicate that the UE is not authorized to announce in this PLMN.
6.4.3.5 DIAMETER_ERROR_INVALID_APPLICATION_CODE (5632)
This result code shall be sent by the ProSe Function in the local PLMN to indicate that none of the ProSe Application Code(s) received in the request is valid.
6.4.3.6 DIAMETER_ERROR_PROXIMITY_UNAUTHORIZED (5633)
This result code shall be sent by the ProSe Function in the serving PLMN to indicate that the Proximity request is not authorized by the user.
6.4.3.7 DIAMETER_ERROR_PROXIMITY_REJECTED (5634)
This result code shall be sent by the ProSe Function in the serving PLMN to indicate that it is unlikely that UEs enter into proximity for the received time window.
6.4.3.8 DIAMETER_ERROR_NO_PROXIMITY_REQUEST (5635)
This result code shall be sent by the ProSe Function in the serving PLMN to indicate that there is no context associated with EPC ProSe User Identities included in the request.
6.4.3.9 DIAMETER_ERROR_UNAUTHORIZED_SERVICE_IN_THIS_PLMN (5636)
This result code shall be sent by the ProSe Function HPLMN to indicate that ProSe is not authorized to announce in this PLMN.
6.4.3.10 DIAMETER_ERROR_PROXIMITY_CANCELLED (5637)
This result code shall be sent by the ProSe Function triggering the Proximity Request to indicate that the cancellation of the Proximity Request procedure as it determines that the UEs are unlikely to enter proximity within the requested time window.
6.4.3.11 DIAMETER_ERROR_INVALID_DISCOVERY_TYPE (5641)
This result code shall be sent by the ProSe Function to indicate that the Discovery Tpe in the request message is not supported.
6.4.3.12 DIAMETER_ERROR_INVALID_TARGET_PDUID (5638)
This result code shall be sent by the ProSe Function to indicate that the PDUID is not belonging to this ProSe Function.
6.4.3.13 DIAMETER_ERROR_INVALID_TARGET_RPAUID (5639)
This result code shall be sent by the ProSe Function to indicate that the target RPAUID is not allowed to be discovered.
6.4.3.14 DIAMETER_ERROR_NO_ASSOCIATED_RESTRICTED_CODE (5640)
This result code shall be sent by the ProSe Function to indicate that the there is no allocated ProSe Restricted Code for the requested target.
6.4.3.15 DIAMETER_ERROR_REVOCATION_FAILURE (56×1)
This value is used to indicate that the ProSe Function was unable to successfully complete the revocation procedure (in an operator-configured time period).
6.4.3.16 DIAMETER_ERROR_ALREADY_BANNED (56×2)
This value is used to indicate that the ProSe Function has determined that the revocation is not necessary because the target RPAUID has already been banned for discovery.
6.4.4 Transient Failures
Result codes that fall within the transient failures category shall be used to inform a peer that the request could not be satisfied at the time it was received, but may be able to satisfy the request in the future. The Result-Code AVP values defined in the Diameter base protocol specified in IETF RFC 6733 [29] shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent.
Annex A (normative):
Diameter overload control mechanism
A.1 General
Diameter overload control mechanism is an optional feature.
IETF RFC 7683 [21] specifies a Diameter overload control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes.
It is recommended to make use of IETF RFC 7683 [21] on the PC6/PC7 interface where, when applied, the requesting ProSe Function shall behave as a reacting node and the responding ProSe Function as a reporting node.
A.2 Responding ProSe Function behaviour
The responding ProSe Function requests traffic reduction from requesting ProSe Function when it is in an overload situation, including OC-OLR AVP in answer commands as described in IETF RFC 7683 [21].
The ProSe Function identifies that it is in an overload situation by implementation specific means. For example, the ProSe Function may take into account the traffic over the PC6/PC7 interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc.
The ProSe Function determines the specific contents of OC-OLR AVP in overload reports and the ProSe Function decides when to send OC-OLR AVPs by implementation specific means.
A.3 Requesting ProSe Function behaviour
The requesting ProSe Function applies required traffic reduction received in answer commands to subsequent applicable requests, as per IETF RFC 7683 [21].
Requested traffic reduction is achieved by the requesting ProSe Function by implementation specific means. For example, it may implement message throttling with prioritization or a message retaining mechanism for operations that can be postponed.
As a result of the need to throttle traffic, the requesting ProSe Function may reject Registration Request, Discovery Request, Match Report Requests initiated by UEs. The possible related error messages used over PC3 are described in the 3GPP TS 24.334 [22].
Annex B (Informative):
Diameter overload node behaviour
B.1 Message prioritization
This clause describes possible behaviours of the requesting ProSe Function receiving an overload indication from the responding ProSe Function, regarding message prioritisation in an informative purpose.
The requesting ProSe Function may take the following into account when making throttling decisions:
– Identification of the procedures that can be deferred (e.g. Proximity Requests), so to avoid to drop non deferrable procedures;
– Prioritisation of certain types of request (e.g. between ProSe-Proximity-Request (PRR) and ProSe-Location-Update-Request (PLR)) according to the context of their use, in particular:
– Higher prioritisation for commands that are related to a registered user for a service, so to avoid the interruption of the registered service for the user.
Annex C (normative):
Diameter message priority mechanism
C.1 General
IETF RFC 7944 [27] specifies a Diameter routing message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied.
C.2 PC6/PC7 interfaces
C.2.1 General
The Diameter message priority mechanism is an optional feature.
It is recommended to make use of IETF RFC 7944 [27] over the PC6/PC7 interfaces of an operator network when the overload control defined in Annex A is applied on these PC6/7 interfaces.
C.2.2 ProSe Function behaviour
When the ProSe Function supports the Diameter message priority mechanism over the PC6 or the PC7 interface, the ProSe Function shall comply with IETF RFC 7944 [27].
The ProSe Function sending a request shall determine the required priority according to its policies. When priority is required, the ProSe Function shall include the DRMP AVP indicating the required priority level in the requests it sends, and shall prioritise the request according to the required priority level.
When the ProSe Function receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request.
When the ProSe Function receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, the ProSe Function may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response.
If:
– the ProSe Function supports using the Diameter message priority mechanism for DSCP marking purposes,
– the transport network utilizes DSCP marking, and
– message-dependant DSCP marking is possible for the protocol stack transporting Diameter,
then the ProSe Function shall set the DSCP marking for transport of the request or response according to the required priority level.
The ProSe Function decisions for a required priority and for the priority level value are implementation specific.
Diameter requests related to high priority traffic shall contain a DRMP AVP with a high priority of which the level value is operator dependent.
Annex D (normative):
Diameter load control mechanism
D.1 General
Diameter load control mechanism is an optional feature.
IETF RFC 8583 [28] specifies a Diameter load control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes.
It is recommended to make use of IETF RFC 8583 [28] on the PC6/PC7 interface where, when applied, the requesting ProSe Function shall behave as a reacting node and the responding ProSe Function as a reporting node.
D.2 Responding ProSe Function behaviour
The responding ProSe Function may report its current load by including a Load AVP of type HOST in answer commands as described in IETF RFC 8583 [28].
The responding ProSe Function calculates its current load by implementation specific means. For example, the responding ProSe Function may take into account the traffic over the PC6/PC7 interface or other interfaces, the level of usage of internal resources (e.g. CPU, memory), the access to external resources, etc.
The responding ProSe Function determines when to send Load AVPs of type HOST by implementation specific means.
D.3 Requesting ProSe Function behaviour
When performing next hop Diameter Agent selection for requests that are routed based on realm, the requesting ProSe Function may take into account load values from Load AVPs of type PEER received from candidate next hop Diameter nodes, as per IETF RFC 8583 [28].
Annex E (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2014-04 |
CT4#64bis |
C4-140705 |
TR Skeleton |
0.1.0 |
|||
|
2014-05 |
CT4#65 |
C4-141079 |
Proposed text for clause "Scope" |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141080 |
General Description of TS 29.345 |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141081 |
Description of the ProSe Service Authorization Procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141082 |
Description of the Direct Discovery Authorization procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141084 |
Description of the Match Report Procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141086 |
Description of the Proximity request Procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141087 |
Description of the Location Update procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141088 |
Description of the Cancellation procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141089 |
Description of Protocol Specification and Implementation |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141090 |
Description of the Proximity Alert Procedure |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141091 |
Description of Information Elements |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141092 |
Description of Commands |
0.2.0 |
|||
|
2014-05 |
CT4#65 |
C4-141175 |
Description of Result Codes |
0.2.0 |
|||
|
2014-07 |
CT4#66 |
C4-141266 |
Editorial corrections |
0.3.0 |
|||
|
2014-07 |
CT4#66 |
C4-141422 |
Removal of the Cancellation-Type AVP |
0.3.0 |
|||
|
2014-07 |
CT4#66 |
C4-141423 |
Domain Name used for ProSe related Diameter Applications |
0.3.0 |
|||
|
2014-07 |
CT4#66 |
C4-141511 |
Description of the Match Report Info procedure |
0.3.0 |
|||
|
2014-07 |
CT4#66 |
C4-141512 |
Correction of the User-Identifier AVP |
0.3.0 |
|||
|
2014-07 |
CT4#66 |
C4-141641 |
Correction of the Discovery-Filter AVP |
0.3.0 |
|||
|
2014-09 |
CT#65 |
CP-140498 |
Presented for information and approval |
1.0.0 |
|||
|
2014-09 |
CT#65 |
Approved at CT#65 |
12.0.0 |
||||
|
2014-12 |
CT#66 |
CP-140778 |
0006 |
1 |
ProSe Validity Timer to VPLMN |
12.1.0 |
|
|
2014-12 |
CT#66 |
CP-140778 |
0003 |
1 |
Overload Control management |
12.1.0 |
|
|
2014-12 |
CT#66 |
CP-140778 |
0007 |
1 |
Wrong P-CR implementations |
12.1.0 |
|
|
2014-12 |
CT#66 |
CP-140778 |
0005 |
Clarification in the ProSe Direct Discovery Authorization Procedure |
12.1.0 |
||
|
2014-12 |
CT#66 |
CP-140778 |
0001 |
4 |
Clarification on ProSe Application Code and Discovery Filter IE Formats |
12.1.0 |
|
|
2014-12 |
CT#66 |
CP-140778 |
0009 |
1 |
Deletion of the unused AVP |
12.1.0 |
|
|
2014-12 |
CT#66 |
CP-140778 |
0010 |
1 |
Updates of the values for Application ID, Command codes, AVP codes and Experimental-Result codes |
12.1.0 |
|
|
2015-03 |
CT#67 |
CP-150028 |
0012 |
2 |
Correction on ProSe Service Authorization Procedures in PC6/PC7 interface |
12.2.0 |
|
|
2015-03 |
CT#67 |
CP-150028 |
0014 |
2 |
Addition of Integrity Check aspects to ProSe Match Report procedure |
12.2.0 |
|
|
2015-03 |
CT#67 |
CP-150028 |
0016 |
1 |
Correction in the Discovery Type description |
12.2.0 |
|
|
2015-03 |
CT#67 |
CP-150028 |
0020 |
2 |
Location Update Trigger |
12.2.0 |
|
|
2015-03 |
CT#67 |
CP-150149 |
0015 |
4 |
Introduction of Authorized Discovery Range Indication for announcing UE |
12.2.0 |
|
|
2015-03 |
CT#67 |
CP-150031 |
0021 |
1 |
Update of the reference for IETF draft-ietf-dime-ovli |
12.2.0 |
|
|
2015-06 |
CT#68 |
CP-150257 |
0022 |
1 |
Addition of Match Report Refresh Timer in PMA command |
12.3.0 |
|
|
2015-06 |
CT#68 |
CP-150257 |
0024 |
1 |
Corrections of errors and inconsistencies in TS 29.345 |
12.3.0 |
|
|
2015-06 |
CT#68 |
CP-150257 |
0025 |
2 |
Ambiguity in the definition of Prose-Discovery-Filter AVP |
12.3.0 |
|
|
2015-06 |
CT#68 |
CP-150257 |
0027 |
2 |
Clarification on ProSe Validity Timer |
12.3.0 |
|
|
2015-06 |
CT#68 |
CP-150257 |
0028 |
2 |
Alignment on using ProSe service and ProSe |
12.3.0 |
|
|
2015-12 |
CT#70 |
CP-150755 |
0032 |
4 |
Correction of AVP and message definitions to allow Diameter command reuse |
12.4.0 |
|
|
2015-12 |
CT#70 |
CP-150755 |
0033 |
1 |
Metadata in Match-Report |
12.4.0 |
|
|
2015-12 |
CT#70 |
CP-150759 |
0035 |
1 |
Reference to DOIC updated with IETF RFC 7683 |
12.4.0 |
|
|
2015-12 |
CT#70 |
CP-150772 |
0029 |
5 |
Addition of ProSe discovery service authorization for restricted discovery |
13.0.0 |
|
|
2015-12 |
CT#70 |
CP-150772 |
0030 |
2 |
ProSe Open Discovery for Dynamic Metadata |
13.0.0 |
|
|
2015-12 |
CT#70 |
CP-150772 |
0031 |
2 |
AVP and Message format changes for new ProSe procedures |
13.0.0 |
|
|
2015-12 |
CT#70 |
CP-150772 |
0034 |
2 |
Addition of ProSe match report info for restricted discovery |
13.0.0 |
|
|
2016-03 |
CT#71 |
CP-160023 |
0041 |
Diameter message priority over PC6/PC7 |
13.1.0 |
||
|
2016-03 |
CT#71 |
CP-160036 |
0036 |
3 |
Monitoring update and Reporting of update result |
13.1.0 |
|
|
2016-03 |
CT#71 |
CP-160036 |
0037 |
1 |
Inter-PLMN discovery transmission support |
13.1.0 |
|
|
2016-03 |
CT#71 |
CP-160036 |
0038 |
1 |
Adding security related parameters for restricted ProSe direct discovery authorization |
13.1.0 |
|
|
2016-03 |
CT#71 |
CP-160036 |
0039 |
1 |
Support open discovery with application-controlled extension |
13.1.0 |
|
|
2016-03 |
CT#71 |
CP-160036 |
0040 |
– |
Discovery update for open and restricted ProSe direct discovery |
13.1.0 |
|
|
2016-06 |
CT#72 |
CP-160232 |
0042 |
2 |
Update of AVP codes for ProSe direct discovery security and open ProSe direct discovery with application-controlled extension |
13.2.0 |
|
|
2016-06 |
CT#72 |
CP-160232 |
0043 |
1 |
Clarification of local PLMN usage in direct discovery authorization |
13.2.0 |
|
|
2016-12 |
CT#74 |
CP-160664 |
0045 |
– |
Correction to change IETF drmp draft version to official RFC 7944 |
13.3.0 |
|
|
2016-12 |
CT#74 |
CP-160681 |
0044 |
1 |
Load Control |
14.0.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0046 |
1 |
Update of reference for the Diameter base protocol |
14.1.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0047 |
1 |
Handling of the Vendor-Specific-Application-Id AVP |
14.1.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0048 |
1 |
Cardinality of the Failed-AVP AVP in answer |
14.1.0 |
|
|
2017-06 |
CT#76 |
CP-171018 |
0050 |
1 |
Support for signaling transport level packet marking |
14.2.0 |
|
|
2017-09 |
CT#77 |
CP-172013 |
0052 |
– |
Correction of DRMP Procedures |
14.3.0 |
|
|
2017-12 |
CT#78 |
CP-173032 |
0053 |
1 |
Updates for WLAN based ProSe Direct Discovery |
15.0.0 |
|
|
2019-09 |
CT#85 |
CP-192094 |
0055 |
1 |
draft-ietf-dime-load published as RFC 8583 |
15.1.0 |
|
|
2020-07 |
CT#88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
|
2022-04 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |