(4A): 5-1). CER/CEA, 5-2) RAR/RAA, 5-3) AAR/AAA, 5-4) DER/DEA
(4B): 5-5A). (Rf) ACR/ACA; 5-5B). (Ro) CCR/CCA; 5-6). (Re) PRQ/PRS + TRQ/PRS + SUQ/SUS (Charging related)
(4C): 5-7). AS/ASA; 5-8). STR/STA
(4D): 5-9). DWR/DWA; 5-10). DPR/DPA
(4E): 5-11). UAR/UAA; 5-12). SAR/SAA; 5-13). LIR/LIA; 5-14). MAR/MAA; 5-15). RTR/RTA; 5-16). PPR/PPA
(4F): 5-17). UDR/UDA; 5-18). PUR/PUA; 5-19). SNR/SNA; 5-20). PNR/PNA
(4G): 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)
http://docs.google.com/View?id=ddh56dhg_289dw7k3dgd
5.1. (257) Capabilities-Exchange-Request / Answer (CER and CEA):
§ When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages. This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc
§ After establishing the transport connection, between two nodes shall advertise the support for the following three (Gx/Rx/Gxx) specific Application by including
§ the value of the application identifier in the Auth-Application-Id AVP and
§ the value of the 3GPP (10415) in the Vendor-Id AVP
of the Vendor-Specific-Application-Id AVP contained in the Capabilities‑Exchange-Request and Capabilities-Exchange-Answer commands
1. Gx for Between PCRF and PCEF nodes
2. Gxx for Between PCRF and BBERF nodes
3. Rx for Between PCRF and AF nodes
5.2. (258) Re-Auth-Request / Answer (RAR and RAA):
§ A Diameter server may initiate a re-authentication and/or re-authorization service for a particular session by issuing a Re-Auth-Request (RAR).
§ For example, for pre-paid services, the Diameter server that originally authorized a session may need some confirmation that the user is still using the services.
(RFC 4005 - NAS)
§ If a NAS (access device) receives an RAR message with Session-Id equal to a currently active session and a Re-Auth-Type that includes authentication, it MUST initiate a re-authentication toward the user, if the service supports this particular feature.
1. G9 for Between H-PCRF and V-PCRF
§ The RAR command, is sent by the H-PCRF to the V-PCRF in order to provision QoS/PCC rules and event triggers for the sub-session/session.
2. Gx for Between PCRF and BBERF/PCEF
§ The RAR command is sent by the PCRF to the BBERF/PCEF in order to provision QoS/PCC rules using the PUSH procedure initiate the provision of unsolicited QoS/PCC rules. It is used to provision QoS/PCC rules, event triggers and event report indications for the session.
§ The RAR command is sent by the PCRF to the AF in order to indicate an Rx specific action:
§ For Bearer Release, the CRF (or PCRF) shall use the following procedures to notify the AF: either via ASR/STR or via RAR. Within the RA-Request, the CRF (or PCRF) shall set the value for the Specific-Action AVP to INDICATION_OF_TERMINATION_OF_BEARER, shall indicate the affected IP flows with the Flows AVP(s) and shall provide the appropriate Abort-Cause AVP value.
§ Service Data Flow Deactivation via RAR message (29.214)
§ Notification of Signalling Path Status via RAR message (29.214)
§ IP-CAN type change Notification via RAR message (29.214)
§ Access Network Charging Information Notification via RAR message (29.214)
§ Gmb for Between BM-SC and GGSN or SGmb for Between eBM-SC and MBMS-GW
§ The BM-SC initiates the MBMS session start procedure (via RAR) when it is ready to send data. This informs the GGSN of the imminent start of the transmission and MBMS session attributes are provided to the GGSNs included in the list of downstream nodes in BM-SC. For a multicast MBMS service these are the GGSNs that have previously registered for the corresponding MBMS bearer service. The bearer plane is allocated
§ The BM-SC initiates the MBMS session stop procedure (via RAR) when it considers the MBMS session terminated. Typically this will happen when there is no more MBMS data expected to be transmitted for a sufficiently long period of time to justify the release of bearer plane resources in the network.
§ The BM-SC initiates the MBMS session update procedure (via RAR) when the service area for an ongoing MBMS session shall be modified. This procedure is defined only for MBMS broadcast services.
(In WLAN)
1. Wa for Between AAA-Server --- WLAN AN
§ The 3GPP AAA server issues an unsolicited re-authentication and re-authorization request towards the WLAN AN.
§ This procedure is mapped to the Diameter command codes Re-Auth-Request and Re-Auth-Answer specified in RFC 3588
2. Wd for Between AAA-Server --- AAA-Proxy
§ It is used to transport the WLAN Access Authentication and Authorization information between the 3GPP AAA Proxy and the 3GPP AAA Server.
3. Wm for Between AAA-Server --- PDG
§ The 3GPP AAA server issues an unsolicited re-authentication and/or re-authorization request towards the PDG.
§ This procedure is mapped to the Diameter command codes Re-Auth-Request and Re-Auth-Answer specified in RFC 3588
(In EPS AAA)
§ Service Authorization Information Update Procedures (RAR/RAA)
§ This “Authorization Information Update” procedure via RAR command shall be used between following nodes (see below) for the purpose of modifying the previously provided authorization parameters.
§ This may happen due to a modification of the subscriber profile in the HSS (for example, removal of a specific APN associated with the subscriber).
1. SWa Between AAA Server/Proxy and Untrusted Non-3GPP IP Access
§ The “Service Authorization information update” is not supported by SWa.
2. STa Between AAA Server/Proxy and Trusted Non-3GPP IP Access
§ The Diameter Re-Auth-Request (RAR) command is sent from a 3GPP AAA server to a Trusted non-3GPP access network NAS.
§ Access & Service Authorization information update procedure performed in two steps:
§ Step 1: The 3GPP AAA server issues an unsolicited re-authorization request towards the trusted non-3GPP access via RAR command.
§ Step 2: Upon receiving the re-authorization request, the non-3GPP access shall immediately invoke the STa non-3GPP access authorization procedure
3. SWm for Between AAA-Server/Proxy and ePDG (AAA/PDG for WLAN/WAG)
§ The Re-Auth-Request (RAR) command is sent from a 3GPP AAA Server/Proxy to a ePDG.
§ This procedure shall be performed in two steps:
§ Step 1: The 3GPP AAA Server shall issue an unsolicited re-authorization request towards the ePDG. Step 2: Upon receiving the re-authorization request, the ePDG shall immediately invoke the authorization procedure for the session indicated in the request.
4. S6b Between AAA-Server/Proxy and PDN-GW (EPS P-GW)
§ The Diameter Re-Auth-Request (RAR) command is sent from a 3GPP AAA Server or 3GPP AAA Proxy to a PDN-GW.
§ The S6b reference point allows the 3GPP AAA server to modify the authorization information previously provided to the PDN GW, i.e. during Service Authentication and Authorization when using DSMIPv6, or Service Authorization using PMIPv6 or MIPv4, or the service authorization information provided during a previous Service Authorization update.
§ This procedure is triggered by the modification of the non-3GPP profile of the UE or by activating or deactivating subscriber and equipment trace in the HSS.
§ The Service Authorization Information Update procedure is performed in two steps:
§ Step 1: The 3GPP AAA server issues an unsolicited re-authentication and/or re-authorization request towards the PDN GW.
§ Step 2: After receiving the re-authorization request, the PDN GW invokes for the indicated APN. The authorization procedure is for PMIPv6 or DSMIPv6.
(DCCA for Re-authorization in 32.299)
§ Support of Re-authorization: between IMS Nodes and OCS in DCCA Charging session
§ Mid Diameter CC session re-authorizations of multiple active resource quotas within a DCC session can be achieved using a single Diameter Credit Control Request/Answer (CCR/CCA) message sequence.
§ The OCS may also re-authorize multiple active resource quotas within a DCC session by using a single Diameter Re-Auth-Request/Answer (RAR/RAA) message sequence.
5.3. (265) AA-Request / Answer (AAR and AAA):
(RFC 4005 - NAS)
§ The AA-Request is used to request authentication and/or authorization for a given NAS user.
§ This AA-Request message MAY be the result of a multi-round authentication exchange.
§ A request for authorization SHOULD only include the information from which the authorization will be performed, such as the User-Name, Called-Station-Id, or Calling-Station-Id AVPs.
(For External PDN or other network)
1. Gi Between GGSN and Diameter Server for External PDN or other network
§ When a GGSN receives a Create PDP Context Request message for a given APN, the GGSN may (depending on the configuration for this APN) send a Diameter AA-Request to a Diameter server (like HLR/HSS for authentication or OFCS for accounting).
§ The Diameter server authenticates and authorizes the user.
2. SGi Between EPC/P-GW and Diameter Server for External PDN or other network
§ When a P-GW receives an initial access request (e.g. Create Session Request or Proxy Binding Update) message for a given APN, the P-GW may (depending on the configuration for this APN) send a Diameter AA-Request to a Diameter server (like HLR/HSS for authentication or OFCS for accounting).
§ The Diameter server authenticates and authorizes the user.
1. Gmb for Between BM-SC and GGSN or SGmb for Between eBM-SC and MBMS-GW
(1.1). Service activation:
§ After the GGSN receives an IGMP (IPv4) or MLD (IPv6) Join message from a UE, over the default PDP context to signal its interest in receiving a particular multicast MBMS bearer service identified by an IP multicast address.
§ The GGSN sends an
(1.2). Registration procedure:
§ The GGSN sends a
a). When the GGSN has no MBMS Bearer Context for an MBMS bearer service and the GGSN receives an MBMS Registration from an SGSN for this MBMS bearer service, or
b). When the first MBMS UE Context is created in the GGSN for an MBMS bearer service for which the GGSN has no MBMS Bearer Context,
(1.3). Trace Session Activation procedure :
§ When the GGSN has received a Trace Activation message from the SGSN, in a Create MBMS Context Request/Update MBMS Context Request, that requires the activation of a Trace Session in the BM-SC, the GGSN sends an AAR message (containing the IMSI and the Additional MBMS Trace Info AVPs) to activate a trace session in the BM-SC.
(1.4). MBMS UE Context Modification Procedure:
§ The MBMS UE Context shall be updated when the UE enters a new Routing Area (RA) served by a new SGSN or the UE is transitioning between UTRAN and GERAN or vice versa
§ GGSN shall pass the relevant data via the Gmb interface to enable the BM-SC to update its MBMS UE context accordingly.
§ The GGSN sends updated MBMS UE Context parameters (RAI, and CGI/SAI to BM-SC in an
(2.1). Service Activation:
§ The MBMS user traffic is provided by the BM-SC in home PLMN and proxyed.
§ A visited PLMN may offer to roaming users MBMS user services from their home PLMN.
§ For the PDP connection will be used for the JOIN step, may be from the UE to the visited GGSN due to operator policy or routing optimization.
§ The visited GGSN sends an
§ The authorization is done in the BM-SC in visited PLMN with the authorization information retrieved from the BM-SC in home PLMN.
§ The GGSN sends another
1. Rx for Between PCRF and AF
(1.1). Initial Provisioning of Session Information
§ When a new AF session is being established and media information for this AF session is available at the AF and the related media require PCC supervision, the AF shall open an Rx Diameter session with the PCRF for the AF session using an AA-Request command.
§ The AF shall provide the UE's IP address and the corresponding Service Information within Media-Component-Description AVP(s).
(1.2). Modification of Session Information
§ The AF may modify the session information at any time (e.g. due to an AF session modification or internal AF trigger) sending an AA-Request command to the PCRF containing the Media-Component-Description AVP(s) with the updated Service Information.
§ If the AF provides service information that has fully negotiated (e.g. based on the SDP answer), the AF may include the Service-Info-Status AVP set to FINAL_SERVICE_INFORMATION.
(1.3). Gate Related Function
§ The AF may indicate to the PCRF as part of the Media-Component-Description AVP(s) whether the IP flows should be enabled or disabled at the bearer level.
§ The PCRF may receive a separate AA-Request message(s) from the AF to enable or disable IP flows based on the received Service Information, the PCRF may decide to install or remove the corresponding Charging Rule(s).
§ In response to this action the PCRF shall set the appropriate gate status for the corresponding active PCC rule(s).
(1.4). Subscription to Notification of Signalling Path Status
§ An AF may subscribe to notifications of the status of the AF Signalling transmission path.
§ The AF shall open an Rx Diameter session with the PCRF for the AF signalling using an AA-Request command. The AF shall provide the UE's IP address and the Specific-Action AVP requesting the subscription status.
(1). Wd for between AAA-Server and AAA-Proxy
§ Authorization Information Update Procedure:
(2). Wm for between AAA-Server/proxy and ePDG:
§ Access and Service Authorization Information Update Procedure:
§ The Wm reference point performs authorization download based on the reuse of the NASREQ IETF RFC 4005 AAR-AAA command set
(3). Wg for Between AAA-Server/-Proxy and WAG
§ The Wg Policy Download Request/Response are mapped onto the NASREQ
§ The policy download procedure is used:
- between the 3GPP AAA Server and the WAG in the case where the PDG is in the HPLMN
- between the 3GPP AAA Proxy and the WAG in the case where the PDG is in the VPLMN
§ The Wg reference point performs routing policy download based on the reuse of the NASREQ IETF RFC 4005 [AAR-AAA command set.
§ If the WAG is located in the VPLMN, the 3GPP AAA Server shall send the
§ The way to find the WAG address in AAA proxy/AAA server is implementation dependent.
§ For example, based on the source IP address of DER command if the WAG has the NAT functionality or manual network configuration.
(4). Pr Between the 3GPP AAA Server and the PNA
§ An indication of the W-APN Activation to the PNA.
§ The W-APN Activation Indication Request/Response are mapped onto the NASREQ AAR/AAA messages.
(In EPS AAA)
(1) SWa for between 3GPP AAA server and Non-Trusted non-3GPP access network NAS)
§ Same as STa Access and Service Authorization information update
(2) STa for 3GPP AAA server and Trusted non-3GPP access network NAS
§ Access & Service Authorization information update procedure performed in two steps:
§ The 3GPP AAA server issues an unsolicited re-authorization request via RAR the trusted non-3GPP access. Upon receipt of such a request, the trusted non-3GPP access shall respond to the request and indicate the disposition of the request.
(3) SWm for Between the ePDG and 3GPP AAA Server and Proxy.
§ Authorization Procedures:
§ It shall be invoked by the ePDG, upon receipt of a valid Re-Authorization Request message from the 3GPP AAA Server
§ The procedure shall be used by the ePDG to update the previously provided authorization parameters. This may happen due to a modification of the subscriber profile in the HSS (for example, removal of a specific APN associated with the subscriber).
(4) S6b for Between the 3GPP AAA Server and the PDN-GW
§ The procedure is mapped to the Diameter command codes AA-Request (AAR) and AA-Answer (AAA) specified in RFC 4005
§ The PDN GW shall update its address information to the 3GPP AAA Server and HSS.
§ Static QoS profile information may also be downloaded at the same time.
§ Authorization Procedures when using PMIPv6: The following authorization procedures take place upon a reception of a PBU at the PDN GW from the MAG.
§ Authorization Procedures when using MIPv4 FACoA: The following authorization procedures take place upon a reception of a RRQ at the PDN GW from the FA.
5.4. (268) Diameter-EAP-Request (DER and DEA):
(RFC 4072: EAP)
§ The Diameter EAP application defines new Command-Codes and Attribute-Value Pairs (AVPs), and can work together with RADIUS EAP support [RFC3579].
§ The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server.
§ In the Diameter EAP application, authentication occurs between the EAP client and its home Diameter server.
§ Diameter-EAP-Answer message may include a Master Session Key (MSK) for protecting the communication between the user and the NAS
§ EAP Procedures:
§ The access device will typically send a Diameter-EAP Request message with an empty EAP-Payload AVP to the Diameter server, signifying an EAP-Start.
§ If the Diameter home server is willing to do EAP authentication, it responds with a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP packet.
§ The EAP payload is forwarded by the access device to the EAP client.
§ Some EAP Scenarios: (N/A – See Message Flows in RFC 4072)
§ EAP Scenario 1: Direct Connection: The simplest case is when the NAS contacts the home server directly.
§ EAP Scenario 2: Direct Connection with Redirect: In this scenario the NAS uses a redirect agent to locate the home server.
§ EAP Scenario 3: Direct EAP, Authorization via Agents: In this scenario the EAP authentication is done directly with the home server and authorization AVPs are retrieved from local proxy agents.
§ EAP Scenario 4: Proxy Agents: This scenario is the same as Scenario 1, but the NAS contacts the home server through proxies.
§ Basic Diameter security mechanisms (IPsec and TLS) protect Diameter messages hop-by-hop.
(In WLAN)
1. Wa Between the WLAN AN and the 3GPP AAA Proxy or Server
§ WLAN Access Authentication and Authorization:
§ This procedure is used to transport over RADIUS or Diameter, the WLAN Access (Re)-Authentication and Authorization between the WLAN AN and the 3GPP AAA Proxy or Server via DER/DEA commands.
2. Wd Between 3GPP AAA Server and 3GPP AAA Proxy
§ The Diameter-EAP-Answer (DEA) command is sent from a 3GPP AAA server to a 3GPP AAA Proxy.
a). Conversion of RADIUS Request to Diameter Request:
§ When receiving a RADIUS Request on the Wa reference point, the 3GPP AAA Proxy Translation Agent shall translate it into a Diameter Request to be forwarded on the Wd reference point, as described in IETF RFC 4005.
§ If the RADIUS Request are taken by the Translation Agent to convert this Radius Request into a Diameter Request containing EAP frames. Typically, RADIUS Access Request command is translated into Diameter-EAP-Request command.
b). WLAN Access Authentication and Authorization:
§ This procedure is used to transport the WLAN Access Authentication and Authorization information via DER/DEA command between the 3GPP AAA Proxy and the 3GPP AAA Server.
3. Wg Between 3GPP AAA Server/Proxy and WAG
§ Policy Download Procedure:
It is used between
§ the 3GPP AAA Server and the WAG in the case where the PDG is in the HPLMN or
§ the 3GPP AAA Proxy and the WAG in the case where the PDG is in the VPLMN
§ The Wg reference point performs routing policy download based on the reuse of the NASREQ IETF RFC 4005 AAR-AAA command set.
§ If the WAG is located in the VPLMN, the 3GPP AAA Server shall send the
4. Wm Between 3GPP AAA Server/Proxy and PDG
§ Wm for Diameter EAP application is used for Authentication and optionally Authorization Request of the user via DER/DEA command.
§ In this case, the PDG shall act as the NAS, as described in 3GPP TS 33.234.
§ The Diameter-EAP-Request (DER) command is sent from PDG to 3GPP AAA Server/Proxy.
§ For authorization only procedure and other Wm functionalities, NASREQ and base protocol procedures are used for carrying messages for service authorization between PDG and 3GPP AAA Server/Proxy.
(In EPS AAA)
1. SWa from a Untrusted non-3GPP access network NAS to a 3GPP AAA Server
§ The first authentication command exchange (DER/DEA) is common between the SWa and STa reference points
2. STa from a trusted non-3GPP access network NAS to a 3GPP AAA Server
§ Diameter usage over the STa interface:
§ When EAP is used, the trusted non-3GPP access authentication and authorization procedure shall be mapped to the DER/DEA command codes specified in IETF RFC 4072.
3. SWd between 3GPP AAA Proxy and 3GPP AAA Server
§ The authentication or authorization request via DER command from a 3GPP AAA Proxy to a 3GPP AAA server for SWd may be in conjunction with SWa (Untrusted non-3GPP AN) or STa (Trusted non-3GPP AN).
§ The Diameter-EAP-Answer (DEA) command is sent from a 3GPP AAA server to a 3GPP AAA Proxy.
4. SWm between 3GPP AAA Server/Proxy and ePDG
§ The authentication and authorization procedure shall be used between the ePDG and 3GPP AAA Server/Proxy. And the Diameter-EAP-Request (DER) command is sent from ePDG to 3GPP AAA Server/Proxy.
§ During the Access Authentication and Authorization procedure, the ePDG may provide information on its PMIPv6 capabilities to the 3GPP AAA Server. The 3GPP AAA Server may perform IP mobility mode selection. The 3GPP AAA Server may provide to the ePDG an indication if either PMIPv6 or local IP address assignment shall be used.
§ When DSMIPv6 is used, to enable HA address discovery based on IKEv2 (see TS 24.303), the 3GPP AAA server may also download PDN GW identity to the ePDG. The PDN Gateway identity is a FQDN and/or IP address of the PDN GW.
§ If DSMIPv6 is used, a single IKE SA is used for all PDN connections of the user.
§ If PMIPv6 is used, a separate IKE SA is created for each PDN connection of the user
§ Each new additional IKE SA shall be handled in a different Diameter session.
5. S6b between 3GPP AAA Server/Proxy and PDN GW
§ Authentication and Authorization Procedures when using DSMIPv6 (DER/DEA)
§ The S6b reference point performs authentication based on reuse of the DER/DEA command set defined in Diameter EAP.
§ PDN GW shall send an Diameter-EAP-Request (DER) with the EAP Payload AVP containing the according EAP-Response to the 3GPP AAA Server / Proxy
§ PDN GW shall then send an IKE_AUTH message containing the according EAP Payload to the UE.
§ On receipt of the DER message, the 3GPP AAA Server shall process the DER message according to 3GPP TS 33.402.
§ The S6b interface shall enable the authentication and authorization between the UE and the 3GPP AAA Server/Proxy for DSMIPv6.
§ The 3GPP AAA Proxy is required to handle roaming cases in which the PDN GW is in the VPLMN.
6. H2 between 3GPP AAA Server and HA
§ The H2 reference point is defined between the 3GPP AAA Server and the HA.
§ For H2, the 3GPP AAA server shall process the DER message according to 3GPP TS 33.234
§ In the context of DSMIPv6 the procedures described in this specification apply to both S6b and H2.
沒有留言:
張貼留言