Protocol OV: (4H) Diameter Command Description

Protocol OV: (4H) Diameter Command Description

5-30). BIR/BIA (in GAA); 5-31). GPR/GPA (in GBA Push); 5-32). MPR/MPA (for MMS);

1). GAA = Generic Authentication Architecture (via Zn)

§ GAA application: is an application that uses the security association created by GBA Bootstrapping procedure.

§ The network architecture of the GAA applications procedure using Zn

§ GAA: UE --- (Ua) --- NAF --- (Zn) --- BSF

§ GBA Push: UE --- (Upa) --- NAF --- (Zpn) --- BSF

§ Two options of Zn protocol: DIAMETER based Zn interface or Web Services (via SOAP/WSDL Message) based Zn interface

§ The requirements for Zn interface are defined in 3GPP TS 33.220.

§ The requirements for Zpn interface are defined in 3GPP TS 33.223

§ The protocol Zn retrieves the key material and possibly user security settings data by NAF from BSF. After UE is authenticated with the BSF, every time the UE wants to interact with an NAF

2). GBA = Generic Bootstrapping Architecture via Zh (to HSS)

§ GBA: UE --- (Ub) --- BSF --- (Zh) --- HSS

§ GBA Push: UE --- (Upa) --- NAF --- (Zpn) --- BSF --- (Zh) --- HSS

§ The Bootstrapping Zh interface performs the retrieval of an authentication vector and possibly GBA User Security Settings from the HSS

§ The network architecture of GBA push procedure using Zpn

§ A NAF sends a bootstrapping push request to the BSF via Zpn interface including the IMPI or IMPU of the user

The BSF starts protocol Zh with user’s HSS (via MAR)

§ The BSF requests user’s authentication vector and GBA User Security Settings (GUSS) corresponding to the IMPI or IMPU.

§ The HSS supplies to the BSF the requested authentication vector and GUSS (if any)

5.30). (310) Bootstrapping-Info-Request / Answer (BIR and BIA) in GAA:

§ (Zn for GAA) BIR/BIA between NAF and BSF

§ The protocol Zn retrieves the key material and possibly user security settings data by NAF from BSF. After UE is authenticated with the BSF, every time the UE wants to interact with an NAF

§ The NAF shall send a Bootstrapping-Info-Request message (BIR) to the BSF.

Message Flow: (N/A)

§ Diameter based GAA (Zn) application procedure (via Diameter BIR)

§ Web Services based GAA (Zn) application procedure (via WSDL BIR)

5.31). (312) GBA-Push-Info-Request / Answer (GPR and GPA) in GBA Push:

§ (Zpn for GBA Push) GPR/GPA between NAF and BSF

§ The NAF shall send a GBA-Push-Info-Request (GPR) message to the BSF.

§ (Zh for GBA) MAR/MAA between BSF and HSS

§ The BSF shall send a MA-Request (MAR) message to the HSS.

§ The Bootstrapping Zh interface performs the retrieval of an authentication vector and possibly GBA User Security Settings from the HSS

Message Flow: (N/A)

§ Diameter based GBA (Zh) push (Zpn) procedure over Zpn (via Diameter GPR)

§ Web Services based GBA (Zh) Push (Zpn) application procedure (via WSDL GPR)

§ GBA (Zh) bootstrapping procedure (via Diameter MAR)

§ GBA (Zh) Push (Zpn) bootstrapping procedure (via Diameter MAR)

5.32. (311) Message-Process-Request (MPR and MPA) in MM10:

MM10: MPR/MPA between MMS Relay/Server and MSCF

§ The Message-Process-Request (MPR) command is sent by a Diameter client (MMS Relay/Server) to a Diameter server (MSCF) in order to request the processing of a multimedia message.

§ The command codes for the MM10 interface application are taken from the range allocated by IANA as assigned in this specification. For these commands, the Application-ID field shall be set to 16777226

§ The vendor identifier value of 3GPP (10415) shall be included

§ The MMS Relay/Server and MSCF shall advertise support of the Diameter MM10 interface Application by including the value of the application identifier

§ Diameter sessions are implicitly terminated between the MMS Relay/Server and the MSCF. An implicitly terminated session is one for which the server does not maintain state information. The client does not need to send any re-authorization or session termination requests to the server.

§ Diameter messages over the MM10 interface shall make use of SCTP IETF RFC 2960 and shall utilise the new SCTP checksum method specified in RFC 3309

§ The MMS Relay/Server shall derive the address/name of the MSCF for a certain user or use case from the MMS user profile or from the MMS Relay/Server configuration.

§ The MMS Relay/Server shall present both the Destination-Realm and Destination-Host AVPs in the request.

§ Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the MMS Relay/Server.

The multimedia message in Diameter application that allows a Diameter client and a Diameter server:

§ to indicate that a submission or delivery request for a multimedia message has been received. The Diameter client provides the message data and additional data qualifying the messaging event to the server.

§ to request in result to continue the processing of the multimedia message with the original or modified information or to reject the multimedia message.

§ MM10 Interrogation Procedure (via MPR)

§ This procedure is used between the MMS Relay/Server and the MSCF.

§ This procedure is invoked by the MMS Relay/Server and is used to request processing of addressing information related to a multimedia message (see 3GPP TS 23.140).

Protocol OV: (4G) Diameter Command Description

Protocol OV: (4G) Diameter Command Description

5-21). ULR/ULA; 5-22). CLR/CLA; 5-23). AIR/AIA; 5-24). IDR/IDA; 5-25). DSR/DSA; 5-26). PUR/PUA; 5-27). RSR/RSA; 5-28). NOR/NOA; 5-29). ECR/ECA;
(S6a/S6d or S13/S13' for EPS/MME or SGSN to HSS/EIR)

5.21. (316) Update-Location-Request / Answer (ULR and ULA):

S6a/S6d: ULR/ULA between MME/SGSN and HSS

ULR/ULA between MME and HSS (MME or SGSN à HSS)

§ The S6a interface enables the transfer of subscriber related data between the MME and the HSS as described in the 3GPP TS 23.401

§ The S6d interface enables the transfer of subscriber related data between the SGSN and the HSS as described in 3GPP TS 23.060

§ The Update-Location-Request (ULR) command is sent from MME or SGSN to HSS.

Update Location (via ULR)

§ 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. The procedure shall be invoked by the MME or SGSN and is used:

§ to inform the HSS about the identity of the MME or SGSN currently serving the user, and optionally in addition;

§ to update MME or SGSN with user subscription data;

§ to provide the HSS with other user data, such as Terminal Information.

§ The MME shall make use of this procedure to update the MME identity stored in the HSS (e.g. at initial attach, inter MME tracking area update or radio contact after HSS reset).

§ The SGSN shall make use of this procedure to update the SGSN identity stored in the HSS (e.g. at initial attach, inter SGSN routing area update or radio contact after HSS reset).

5.22. (317) Update-Location-Request / Answer (CLR and CLA):

S6a/S6d: CLR/CLA between MME/SGSN and HSS

§ CLR/CLA between MME and HSS (HSS à MME or SGSN)

§ The Cancel-Location-Request (CLR) command is sent from HSS to MME or SGSN.

Cancel Location (via CLR)

§ The Cancel Location Procedure shall be used between the HSS and the MME and between the HSS and the SGSN to delete a subscriber record from the MME or SGSN.

§ The procedure shall be invoked by the HSS and is used:

§ to inform the MME or SGSN about the subscriber’s subscription withdrawal or

§ to inform the MME or SGSN about an ongoing update procedure i.e. MME or SGSN change.

§ The HSS shall make use of this procedure when the subscriber’s subscription is withdrawn by the HSS operator and when the HSS detects that the UE has moved to a new MME or SGSN area.

5.23. (318) Authentication- Information-Request / Answer (AIR and AIA):

S6a/S6d: AIR/AIA between MME/SGSN and HSS

§ AIR/AIA between MME and HSS (MME or SGSN à HSS)

§ The Authentication-Information-Request (AIR) command is sent from MME or SGSN to HSS.

§ The MME or SGSN shall make use of this procedure in order to retrieve the Authentication Vectors from the HSS.

§ If the request is triggered by a synchronization failure, the MME or SGSN shall include the Re-Synchronization Information in the request.

Authentication Information Retrieval (via AIR)

§ The Authentication Information Retrieval Procedure shall be used by the MME and by the SGSN to request Authentication Information from the HSS.

5.24. (319) Insert Subscriber Data-Request / Answer (IDR and IDA):

S6a/S6d: IDR/IDA between MME/SGSN and HSS

§ IDR/IDA between MME and HSS (HSS à MME or SGSN)

§ The Insert-Subscriber-Data-Request (IDR) command is sent from HSS to MME or SGSN.

§ When receiving an Insert Subscriber Data request, the MME or SGSN shall check whether the IMSI is known

§ The HSS shall make use of this procedure to replace a specific part of the user data stored in the MME or SGSN with the data sent, or to add a specific part of user data to the data stored in the MME or SGSN.

Insert Subscriber Data (via IDR)

§ The Insert Subscriber Data Procedure shall be used between the HSS and the MME and between the HSS and the SGSN for updating certain user data in the MME or SGSN in the following situations:

§ due to administrative changes of the user data in the HSS and the user is now located in an MME or SGSN, i.e. if the user was given an subscription and the subscription has changed;

§ the operator has applied, changed or removed Operator Determined Barring for this user.

§ activate subscriber tracing in the MME or the SGSN

5.25. (320) Delete-Subscriber-Data-Request / Answer (DSR and DSA):

S6a/S6d: DSR/DSA between MME/SGSN and HSS

§ DSR/DSA between MME and HSS (HSS à MME or SGSN)

§ The Delete-SubscriberData-Request (DSR) command is sent from HSS to MME or SGSN.

§ The HSS shall make use of this procedure to remove deleted subscription data from the MME or SGSN.

Delete Subscriber Data (via DSR)

§ This procedure shall be used between the MME and the HSS and between the SGSN and the HSS, to remove some or all data of the HSS user profile stored in the MME or SGSN.

§ The procedure shall be invoked by the HSS and it corresponds to the functional level operation Delete Subscriber Data (see 3GPP TS 23.401).

It shall be used to remove:

§ all or a subset of the EPS subscription data (APN Configuration Profile) for the subscriber from the MME or SGSN;

§ the regional subscription;

§ the subscribed charging characteristics;

§ the Session Transfer Number for SRVCC;

§ the trace data.

5.26. (321) Purge-UE-Request / Answer (PUR and PUA):

S6a/S6d: PUR/PUA between MME/SGSN and HSS

§ PUR/PUA between MME and HSS (MME or SGSN à HSS)

§ The Purge-UE-Request (PUR) command is sent from MME or SGSN to HSS

UE Purged in the MME

§ The MME shall make use of this procedure to set the "UE Purged in the MME" flag in the HSS when the subscription profile is deleted from the MME database due to MMI interaction or after long UE inactivity.

UE Purged in the SGSN

§ The SGSN shall make use of this procedure to set the "UE Purged in SGSN" flag in the HSS when the subscription profile is deleted from the SGSN database due to MMI interaction or after long UE inactivity.

Purge UE (via PUR)

§ The Purge UE Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to indicate that the subscriber’s profile has been deleted from the MME or SGSN either by an MMI interaction or automatically, e.g. because the UE has been inactive for several days.

5.27. (322) Reset-Request / Answer (RSR and RSA):

S6a/S6d: RSR/RSA between MME/SGSN and HSS

§ RSR/RSA between MME and HSS (HSS à MME or SGSN)

§ The Reset-Request (RSR) command is sent from HSS to MME or SGSN.

§ When receiving a Reset message, the MME or SGSN shall mark all impacted subscriber records "Subscriber to be restored in HSS". The MME or SGSN shall make use of the received HSS-Address and may make use of the received User-Id-List (if any) in order to determine which subscriber records are impacted.

§ The HSS shall make use of this procedure in order to indicate to the MME and SGSN that the HSS has restarted and may have lost the current MME-Identity and SGSN-Identity of some of its subscribers who may be currently roaming in the MME area and SGSN-Identity, and the HSS cannot send a Cancel Location messages or Insert Subscriber Data messages when needed

Reset (via RSR)

§ The Reset Procedure shall be used and initiated by the HSS, after a restart, to indicate to the MME and to the SGSN that a failure has occurred.

5.28. (323) Notify-Request / Answer (NOR and NOA):

S6a/S6d: NOR/NOA between MME/SGSN and HSS

§ NOR/NOA between MME and HSS (MME or SGSN à HSS)

§ The Notify-Request (NOR) command is sent from MME or SGSN to HSS

Notification (via NOR)

§ The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS when an inter MME or SGSN location update does not occur but the HSS needs to be notified about: an update of terminal information;

§ The Notification Procedure shall also be used between the MME and the HSS and between the SGSN and the HSS to notify the HSS about: an assignment/change/removal of PDN GW for an APN;

§ The Notification Procedure shall be used between the MME and the HSS when an inter MME location update does not occur but the HSS needs to be notified about: the need to send a Cancel Location to the current SGSN (which does not support ISR).

§ The Notification Procedure shall be used between the SGSN and the HSS to notify the HSS about: the UE is present or the UE has memory capacity available to receive one or more short messages.

5.29. (324) ME-Identity-Check-Request / Answer (ECR and ECA):

S13/S13': ECR/ECA between MME/SGSN and EIR

§ ECR/ECA between MME and HSS (MME or SGSN à EIR)

§ The ME-Identity-Check-Request (ECR) command is sent from MME or SGSN to EIR

§ The MME or the SGSN shall make use of this procedure to check the ME identity, if the MME or the SGSN is configured to check the IMEI with the EIR.

§ When receiving the ME Identity Check answer from the EIR, the MME or the SGSN shall check the result code and the equipment status. Dependent upon the result, the MME or the SGSN will decide its subsequent actions (e.g. sending an Attach Reject if the EIR indicates that the Mobile Equipment is unknown or blacklisted).

ME Identity Check (via ECR)

§ This Mobile Equipment Identity Check Procedure shall be used between the MME and the EIR and between the SGSN and the EIR to check the Mobile Equipment's identity status (e.g. to check that it has not been stolen, or, to verify that it does not have faults).