1）If the AF provides service information that has been fully negotiated （e.g. based on the SDP answer）, the AF may include the Service-Info-Status AVP set to FINAL_SERVICE_INFORMATION. In this case the PCRF shall authorize the session and provision the corresponding PCC/QoS rules to the PCEF.
2）The AF may additionally provide preliminary service information not fully negotiated yet （e.g. based on the SDP offer） at an earlier stage. To do so, the AF shall include the Service-Info-Status AVP with the value set to PRELIMINARY SERVICE INFORMATION. Upon receipt of such preliminary service information, the PCRF shall perform an early authorization check of the service information.
1）When the PCRF received an Initial AA-Request from the AF, the PCRF shall perform session binding as described in 3GPP TS 29.213.
2）If the PCRF fails in executing session binding, the PCRF responds to the AF with an AA-Answer including the Experimental-Result-Code AVP set to the value IP-CAN_SESSION_NOT_AVAILABLE.
1）If the service information provided in the AA-Request command is rejected （e.g. the subscribed guaranteed bandwidth for a particular user is exceeded）, the PCRF shall indicate in the AA-Answer command the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED.
2）If the service information provided in the AA-Request command is rejected by the PCRF due to a temporary condition in the network （e.g. the user plane in the cell the user is located is congested）, the PCRF may indicate in the AA-Answer the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_TEMPORARY_NOT_AUTHORIZED （4XX1）.
3）The PCRF may also provide a retry-interval within the Retry-Interval AVP in the AA-Answer command to the AF. When the AF receives the re-try interval within the Retry-Interval AVP, the AF shall not send the same service information to the PCRF again （for the same IP-CAN session） until the re-try interval has elapsed.
1）The AF may request notifications of specific IP-CAN session events through the usage of the Specific-Action AVP in the AA-Request command. The PCRF shall make sure to inform the AF of the requested notifications in the event that they take place.
2）The AF may also include the Specific-Action AVP to request notification for certain user plane events, e.g. bearer termination.
1）The AF may include the AF-Application-Identifier AVP into the AA-Request in order to indicate the particular service the AF session belongs to.
2）The AF may include the AF-Charging-Identifier AVP into the AA-Request for charging correlation purposes.
3）The PCRF shall reply with an AA-Answer to the AF. The acknowledgement towards the AF should take place before or in parallel with any required PCC Rule provisioning towards the PCEF and shall include the Access-Network-Charging-Identifier（s） and may include the Access-Network-Charging-Address AVP, if they are available.
1）The AA-Answer message shall also include the IP-CAN-Type AVP, if such information is available. In that case, the AA-Answer message shall also include the RAT type information within the RAT-Type AVP.
解读：
AAA消息中应包含用户的接入类型，报告给IMS域。
7）P-CSCF如果没有收到AAA怎么办？
The behaviour when the AF does not receive the AA Answer, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this specification and based on operator policy.
解读：
AF可能出现以下几种针对AAA的异常情况：
压根没收到AAA
内部AAA消息等待计时器超时之后收到AAA
收到的AAA消息指示出错
那么，这几种场景，AF的处理取决于运营商的策略，不在本规范中制定，或者看下一个版本。
8）如果资源分配不足导致VoLTE专载建立失败，PCRF该怎么办？
If the PCRF fails in installing PCC/QoS rules based on the provided service information due to resource allocation failures as specified in 3GPP TS 29.212 and if requested by the AF, the PCRF shall send an RAR command to the AF with the Specific-Action AVP set to the value INDICATION_OF_FAILED_RESOURCES_ALLOCATION to report the resource allocation failure. The AF shall send an RAA command to acknowledge the RAR command.
The AF may modify the session information at any time （e.g. due to an AF session modification or internal AF trigger） by sending an AA-Request command to the PCRF containing the Media-Component-Description AVP（s） with the updated Service Information.
The AF may include the Rx-Request-Type AVP set to UPDATE_REQUEST in the AAR.
If the AF provides service information that has been fully negotiated （e.g. based on the SDP answer）, the AF may include the Service-Info-Status AVP set to FINAL_SERVICE_INFORMATION. In this cause the PCRF shall authorize the session and provision the corresponding PCC rules to the PCRF.
The AF may additionally provide preliminary service information not fully negotiated yet （e.g. based on the SDP offer） at an earlier stage. To do so, the AF shall include the Service-Info-Status AVP with the value set to PRELIMINARY SERVICE INFORMATION.
解读：
这段跟会话建立（AAR-I）的时候的业务重授权差不多。
2）业务信息的重授权
1）The PCRF shall process the received Service Information according the operator policy and may decide whether the request is accepted or not. If the updated Service Information is not acceptable （e.g. subscribed guaranteed bandwidth for a particular user is exceeded）, the PCRF shall indicate in the AA-Answer command the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED. If the service information provided in the AA-Request command is rejected by the PCRF due to a temporary condition in the network （e.g. the user plane in the cell the user is located is congested）, the PCRF may indicate in the AA-Answer the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_TEMPORARY_NOT_AUTHORIZED （4xx1）. The PCRF may also provide a retry-interval within the Retry-Interval AVP in the AA-Answer command to the AF. When the AF receives the re-try interval within the Retry-Interval AVP, the AF shall not send the same service information to the PCRF again. The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP in the AA-Answer command.
2）If accepted, the PCRF shall update the Service Information with the new information received. Due to the updated Service Information, the PCRF may need to create, modify or delete the related PCC rules as specified in 3GPP TS 29.213 and provide the updated information towards the PCEF following the corresponding procedures specified at 3GPP TS 29.212.
解读：
这块和4.4.1 会话建立时的业务授权基本一致。区别只是AAR-I变成了AAR-U。
如果PCRF接受了AF下发的AAR-U，则需要根据收到的信息更新业务信息，并触发Gx接口的更新
3）IMS和EPC网络的计费关联
The PCRF shall reply with an AA-Answer to the AF. The acknowledgement towards the AF should take place before or in parallel with any required PCC Rule provisioning towards the PCEF and shall include the Access-Network-Charging-Identifier（s） and may include the Access-Network-Charging-Address AVP, if they are available at this moment and have not been yet supplied earlier to the AF.
The AA-Answer message shall include the IP-CAN-Type AVP if such information is available and has not yet been supplied earlier to the AF.
解读：
和前面完全一样，只不过最后加了个补充说明：如果会话建立的时候没发ANCI AVP，那么现在发。
同样，如果会话建立时没有给IMS提供IP-CAN类型，那么现在提供。
4）更新会话的异常场景
If the PCRF does not have an existing session for the Rx session being modified （such as after a PCRF failure）, the PCRF may reject the request with an AA-Answer with the result code set to DIAMETER_UNKNOWN_SESSION_ID.
If the PCRF modifies existing PCC/QoS rules based on the updated service information and the modification fails due to resource allocation failure as specified in 3GPP TS 29.212 and if requested by the AF, the PCRF shall send an RAR command to the AF with the Specific-Action AVP set to the value INDICATION_OF_FAILED_RESOURCES_ALLOCATION to report the modification failure. The AF shall send an RAA command to acknowledge the RAR command.
Depending on the application, in the Service Information provision, the AF may instruct the PCRF when the IP flow（s） are to be enabled or disabled to pass through the IP-CAN. The AF does this by sending the AA-Request message containing the Media-Component-Description AVP（s） that contains the flow status information （in the Flow-Status AVP） for the flows to be enabled or disabled.
In response to this action the PCRF shall set the appropriate gate status for the corresponding active PCC rule（s）.
The PCRF forwards the AF decision to enable or disable the authorized IP flows.
When an AF session is terminated, if the AF had received a successful AA-Answer for the initial AA-Request, the AF shall send a Session-Termination-Request command to the PCRF. Otherwise, the AF shall wait for the initial AA-Answer to be received prior to sending the Session-Termination-Request command to the PCRF.
When the PCRF receives a ST-Request from the AF, including an AF session termination, it shall acknowledge that request by sending a ST-Answer to the AF. Afterwards, it shall free the resources allocated for the corresponding Service Data Flow（s）. In order to do that, the PCRF shall initiate the request for the removal of any related PCC/QoS rules from the PCEF and for the update of the Authorized QoS for the affected IP-CAN bearer following the corresponding procedures specified at 3GPP TS 29.212.
4.4.5 信令通路状态通知的订阅 Subscription to Notification of Signaling Path Status
信令通路状态订阅基本原理
An AF may subscribe to notifications of the status of the AF Signalling transmission path. To do so, the AF shall open an Rx Diameter session with the PCRF for the AF signaling using an AA-Request command. The AF shall provide the UE's IP address （using either the Framed-IP-Address AVP or the Framed-Ipv6-Prefix AVP） and the Specific-Action AVP requesting the subscription to "INDICATION_OF_LOSS_OF BEARER" and/or "INDICATION_OF_RELEASE_OF_BEARER".
The AF shall additionally provide a Media-Component-Description AVP including a single Media-Sub-Component AVP with the Flow-Usage AVP set to the value "AF_SIGNALLING". The Media-Component-Description AVP shall contain the Media-Component-Number AVP set to "0".
When an IP-CAN session is terminated, the PCRF shall inform the AF about the IP-CAN session termination by sending an ASR （abort session request） command to the AF on each active Rx Diameter session.
When the AF receives the ASR command, it shall acknowledge the command by sending an ASA （abort session answer） command to the PCRF.
After that the AF shall initiate an AF session termination procedure as defined in subclause 4.4.4.
解读：
当IP-CAN（EPS承载+Gx口会话）终结时，PCRF给AF通知ASR。
AF回复AAA。并且AF将发起Rx接口会话终结流程（STR/STA）
业务数据流（SDF）的去激活
It may happen that one or more PCC/QoS Rules （i.e. Service Data Flows） are deactivated at the PCEF at a certain time, either permanently or temporarily. When the PCRF gets the knowledge that one or more SDFs have been deactivated, （e.g. due to a bearer release or loss of bearer or out of credit condition）, the PCRF shall inform the AF accordingly if the AF has previously subscribed using the Specific-Action AVP in the AAR command.
When not all the service data flows within the AF session area affected, the PCRF shall inform the AF by sending an RAR （re-authorization request） command. The RAR command shall include the deactivated IP Flows encoded in the Flows AVP and the cause encoded in the Specific-Action AVP.
The AF may then decide to terminate the Rx Diameter session used for the notification of the status of the AF Signalling transmission path.
If the AF has successfully subscribed to change notifications in UE's IP-CAN type and RAT type, the PCRF shall provide the UE's IP-CAN type and RAT type information （if applicable） in the AA-Answer if already known by the PCRF. The PCRF shall also send an RAR command when a corresponding event occurs, i.e. when the UE's IP-CAN type or RAT type changes or becomes available. In this cause the RAR from the PCRF shall include the Specific-Action AVP for the subscribed event and include the IP-CAN-Type AVP, RAT-Type AVP （if applicable） for the UE's new IP-CAN/RAT.
If the AF has subscribed to a notification about Access Network Charging Information, the PCRF shall provide the Access Network Charging Information in the response, if already known by the PCRF. If not available, the PCRF shall provide the Access Network Charging Information by sending a RAR command when the Access Network Charging Information is received from the PCEF.
The RAR shall include the Specific-Action AVP set to the value "CHARGING_CORRELATION_EXCHAGE" and shall include the assigned Access-Network-Charging-Identifer（s） and may include the Access-Network-Charging-Address AVP.
If the AF requests the PCRF to report the access network information （e.g. user location）, the AF shall subscribe to the "ACCESS_NETWORK_INFO_REPORT" within the Specific-Action AVP and shall include the required access network information within the Required-Access-Info AVP.
When the PCRF receives a request to report the access network information from the AF in an AAR command or in an STR command triggered by the AF, if the PCRF determines that the access network does not support the access network information reporting based on the currently used IP-CAN type or the values of the RAT-Type AVP or the PCEF does not support the access network information reporting based on the Supported-Feature AVP, the PCRF shall respond to AF with an AAA or STA command including the NetLoc-Access-Support AVP set to the value of 0 （NETLOC_ACCESS_NOT_SUPPORTED）; otherwise, it shall immediately configure the PCEF to provide such access network information.
When the PCRF then receives the access information from the PCEF, the PCRF shall provide the corresponding access network information to the AF within the 3GPP-User-Location-Info AVP, TWAN-Identifier AVP, User-Location-Info-Time AVP, UE-Local-IP-Address AVP, 3GPP-SGSN-MCC-MNC AVP （if location info is not available） and/or 3GPP-MS-TimeZone AVP in the RAR command. If the information is provided in the RAR command, PCRF shall also provide the ACCESS_NETWORK_INFO_REPORT within Specific-Action AVP.
如果是为被叫UE侧IMS会话建立的预授权，P-CSCF可以（MAY）从SDP offer中提取业务信息发给PCRF。前提是SDP offer中未知名precondition或者precondition信息中指明了本地precondition条件已经满足。本例中，P-CSCF可以将Service-Info-Status值设置为PRELIMINARY SERVICE INFORMATION。
P-CSCF还应从后续的early dialogue（例如PRACK和OK for PRACK、UPDATE和OK for UPDATE）中的SDP offer-answer交互对中提取业务信息，并通过已有的Diameter会话发送AAR给PC RF来下发业务信息，并携带SIP-Forking-Indication AVP并设置值为SEVERAL_DIALOGUES。
