Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.503  Word version:   16.4.1

Top   Up   Prev   Next
0…   4…   5…   6…   6.1.3…   6.1.3.6…   6.2…   6.2.2…   6.3…   6.4…   6.6…   A…

 

4  High level architectural requirementsWord-p. 11
4.1  General requirements
It shall be possible to apply policy and charging control to any kind of 3GPP and non-3GPP accesses defined in TS 23.501.
The policy and charging control framework shall support the roaming scenarios defined in TS 23.501.
The policy and charging control shall be enabled on a per slice instance, per DNN, or per both slice instance and DNN basis.
NOTE:
In single PCF deployment, the PCF will provide all mobility, UE access selection and PDU session related policies that it is responsible for. In deployments where different PCFs support N15 and N7 respectively, no standardized interface between them is required in this release to support policy alignment.
The policy and charging control framework shall fulfil non-session management related requirements as defined in clause 4.2 and session management related requirements as defined in clause 4.3.
Up
4.2  Non-session management related policy control requirements
4.2.1  Access and mobility related policy control requirements
The policy framework shall provide following functionality for the access and mobility enforcement:
  • Policy Control Function (PCF) shall support interactions with the access and mobility policy enforcement in the AMF, through service-based interfaces.
  • The PCF shall be able to provide Access and Mobility Management related policies to the AMF.
  • The PCF shall be able to evaluate operator policies that are triggered by events received from the AMF.
4.2.2  UE policy control requirementsWord-p. 12
The 5GC shall be able to provide policy information from the PCF to the UE. Such policy information includes:
  • Access Network Discovery & Selection Policy (ANDSP): It is used by the UE for selecting non-3GPP accesses network.
  • UE Route Selection Policy (URSP): This policy is used by the UE to determine how to route outgoing traffic. Traffic can be routed to an established PDU Session, can be offloaded to non-3GPP access outside a PDU Session, or can trigger the establishment of a new PDU Session.
  • V2X Policy (V2XP): This policy provides configuration parameters to the UE for V2X communication over PC5 reference point or over PC5 reference point or both. V2X Policies are defined in TS 23.287.
Up
4.2.3  Network status analytics information requirements
The PCF shall be able to collect directly slice specific network status analytic information from NWDAF. NWDAF provides network data analytics (i.e. load level information) to PCF on a network slice level. PCF shall be able to use that data in its policy decisions.
4.2.4  Management of packet flow descriptions
Management of Packet Flow Descriptions (PFDs) refers to the capability to create, update or remove PFDs in the NEF (PFDF) and the distribution from the NEF (PFDF) to the SMF and finally to the UPF. This feature may be used when the UPF is configured to detect a particular application provided by an ASP.
NOTE 1:
A possible scenario for the management of PFDs in the SMF is when an application, identified by an application detection filter in the UPF, deploys a new server or a reconfiguration occurs in the ASP network which impacts the application detection filters of that particular application.
NOTE 2:
The management of application detection filters in the SMF can still be performed by using operation and maintenance procedures.
NOTE 3:
This feature aims for both: to enable accurate application detection at the UPF and to minimize storage requirements for the UPF and the SMF.
The management of PFDs is supported in non-roaming and home-routed scenarios for those ASPs that have a business relation with the home operator.
Up
4.2.5  SMF selection management related policy control requirements [R16]
The policy framework may provide following functionality for the SMF selection management for a PDU session:
  • The Policy Control Function (PCF) may support interactions with the SMF selection functionality in the AMF and the PCF may provide SMF selection management related policies to the AMF;
  • The PCF may provide a policy to the AMF to contact PCF for performing DNN replacement of specific DNNs;
  • The PCF may provide a policy to the AMF to contact PCF for performing DNN replacement for an unsupported DNN.
Up
4.2.6  Support for non-session management related network capability exposure [R16]
Support for network capability exposure enables an AF (e.g. an external ASP) to request the following non-session management related policy control functionality from the NEF:
Up
4.3  Session management related policy control requirementsWord-p. 13
4.3.1  General requirements
It shall be possible for the PCC framework to base decisions upon subscription information, Access Type and the RAT Type.
The PCC framework shall perform Gating Control and discard packets that don't match any service data flow of the active PCC rules. It shall also be possible for the operator to define PCC rules, with wild-carded service data flow filters, to allow sending or receiving packets that do not match any service data flow template of any other active PCC rules.
The PCC framework shall allow the charging control to be applied on a per service data flow and on a per application basis, independent of the policy control.
The PCC framework shall have a binding method that allows the unique association between service data flows and specific QoS Flow.
A single service data flow detection shall suffice for the purpose of both policy control and flow based charging.
A PCC rule may be predefined or dynamically provisioned at establishment and during the lifetime of a PDU Session. The latter is referred to as a dynamic PCC rule.
It shall be possible to take a PCC rule into service, and out of service, at a specific time of day, without any PCC interaction at that point in time.
It shall be possible to take DNN-related policy information into service, and out of service, once validity conditions specified as part of the DNN-related policy information are fulfilled or not fulfilled anymore, respectively, without any PCC interaction at that point in time.
PCC shall be enabled on a per DNN basis at the SMF. It shall be possible for the operator to configure the PCC framework to perform charging control, policy control or both for a DNN access.
The PCC framework shall allow the resolution of conflicts which would otherwise cause a subscriber's Subscribed Guaranteed Bandwidth QoS to be exceeded.
It should be possible to use PCC framework for handling IMS-based emergency service.
It shall be possible with the PCC framework, in real-time, to monitor the overall amount of resources that are consumed by a user and to control usage independently from charging mechanisms, the so-called usage monitoring control.
It shall be possible for the PCC framework to provide application awareness even when there is no explicit service level signalling.
The PCC framework shall support making policy decisions based on subscriber spending limits.
The PCC framework shall support making policy decisions for N6 traffic steering.
Up
4.3.2  Charging related requirementsWord-p. 14
4.3.2.1  General [R16]
In order to allow for charging control on service data flow, the information in the PCC rule identifies the service data flow and specifies the parameters for charging control.
For the purpose of charging correlation between service data flow level and application level (e.g. IMS) as well as on-line charging support at the application level, applicable charging identifiers and Access Type identifiers shall be passed from the PCF to the AF, if such identifiers are available.
4.3.2.2  Charging models [R16]
The PCC charging shall support the following charging models for charging performed by SMF:
  • Volume based charging;
  • Time based charging;
  • Volume and time based charging;
  • Event based charging;
  • No charging.
NOTE:
The charging model - "No charging" implies that charging control is not applicable, and no charging records are generated.
4.3.2.3  Charging requirements [R16]
It shall be possible to apply different rates and charging models depending on a UE's roaming status.
It shall be possible to apply different rates based on the location of a UE.
It shall be possible to apply different rates for specific part of a service, e.g. allow the UE to download a certain volume for one rate, and after this volume has been reached continue with a different rate.
It shall be possible to apply different rates based on the time of day.
It shall be possible to enforce per service data flow, identified by PCC Rule, usage limits on a per UE basis.
It shall be possible to apply different rates depending on the access used to carry a Service Data Flow
It shall be possible to apply an online charging action upon Application Start/Stop events.
It shall be possible to indicate to the SMF that interactions with the CHF are not required for a PCC rule, i.e. to not perform accounting, credit control or recording of usage for the service data flow, in this case no charging information is generated.
Up
4.3.2.4  Examples of Service Data Flow Charging [R16]
There are many different services that may be used within a network, including both user-user and user-network services. Service data flows from these services may be identified and charged in many different ways. A number of examples of configuring PCC rules for different service data flows are described below.
EXAMPLE 1:
A network server provides an FTP service. The FTP server supports both the active (separate ports for control and data) and passive modes of operation. A PCC rule is configured for the service data flows associated with the FTP server for the user. The PCC rule uses a filter specification for the uplink that identifies packets sent to port 20 or 21 of the IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter specification identifies packets sent from port 20 or 21 of the IP address of the server.
EXAMPLE 2:
A network server provides a "web" service. A PCC rule is configured for the service data flows associated with the HTTP server for the user. The PCC rule uses a filter specification for the uplink that identifies packets sent to port 80 of the IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter specification identifies packets sent from port 80 of the IP address of the server.
EXAMPLE 3:
An operator has a specific charging rate for user-user VoIP traffic over the IMS. A PCC rule is established for this service data flow. The filter information to identify the specific service data flow for the user-user traffic is provided by the P CSCF (AF).
Up
4.3.3  Policy control requirementsWord-p. 15
4.3.3.1  Gating control requirements
Gating control shall be applied by the UPF on a per service data flow basis.
To enable the PCF gating control decisions, the AF shall report session events (e.g. session termination, modification) to the PCF. For example, session termination, in gating control, may trigger the blocking of packets or "closing the gate".
Gating Control applies for service data flows of IP type.
4.3.3.2  QoS control requirements
4.3.3.2.1  QoS control at service data flow level
It shall be possible to apply QoS control on a per service data flow basis in the SMF, applicable for service data flows of both IP type and Ethernet type.
QoS control per service data flow allows the PCC framework to provide the SMF with the authorized QoS to be enforced for each specific service data flow. Criteria such as the QoS subscription information may be used together with policy rules such as, service-based, subscription-based, or predefined PCF internal policies to derive the authorized QoS to be enforced for a service data flow.
It shall be possible to apply multiple PCC rules, without application provided information, using different authorised QoS within a single PDU Session and within the limits of the Subscribed QoS profile.
Up
4.3.3.2.2  QoS control at QoS Flow level
It shall be possible for the PCC framework to support control of QoS reservation procedures (UE-initiated or network-initiated). It shall be possible to determine the QoS to be applied in QoS reservation procedures (QoS control) based on the authorised QoS of the service data flows that are applicable to the QoS Flow and on criteria such as the QoS subscription information, service based policies, and/or predefined PCF internal policies.
It shall be possible for the SMF to determine the authorized QoS of a QoS Flow using the PCC rules associated to the QoS Flow, and the SMF shall be able to notify the PCF if the QoS Flow is removed or the GFBR of a QoS Flow can no longer (or can again) be guaranteed.
It shall be possible for the PCC framework to support control of QoS for the packet traffic of the PDU Session.
The PCC framework shall be able to provide policy control in the presence of NAT devices. This may be accomplished by providing appropriate address and port information to the PCF.
The enforcement of the control for QoS reservation procedures for a QoS Flow shall allow for a downgrading or an upgrading of the requested QoS as part of a UE-initiated QoS Flow establishment and modification. The PCC framework shall be able to provide a mechanism to initiate QoS Flow establishment and modification as part of the QoS control.
The PCC framework shall be able to handle QoS Flows that require a guaranteed bitrate (GBR bearers) and QoS Flows for which there is no guaranteed bitrate (non-GBR bearers).
Up
4.3.3.2.3  QoS control at PDU Session levelWord-p. 16
It shall be possible for the PCF to provide the authorized Session-AMBR values, default 5QI/ARP combination for PDU Session of IP type, Ethernet type and unstructured type unconditionally or conditionally, i.e. per PDU Session type and/or RAT type.
It shall be possible for the PCF to request a change of the unconditional or conditional authorized Session-AMBR value(s) at a specific point in time.
4.3.3.3  Subscriber spending limits requirements
It shall be possible to enforce policies based on subscriber spending limits. The CHF shall maintain policy counter(s) to track spending for a subscription. These policy counters must be available in the CHF prior to their use over the N28 interface.
NOTE:
The mechanism for provisioning the policy counters in the CHF is out of scope of this document.
The PCF shall request information regarding the subscriber's spending from the CHF, to be used as input for dynamic policy decisions for the subscriber, using subscriptions to spending limit reports. The CHF shall make information regarding the subscriber's spending available to the PCF using spending limit reports.
Up
4.3.4  Usage monitoring control requirements
The requirements to monitor, both volume and time usage, and report the accumulated usage of network resources apply for PDU Sessions of type IP and Ethernet.
It shall be possible to apply usage monitoring for the accumulated usage of network resources on a per Session and user basis. This capability is required for enforcing dynamic policy decisions based on the total network usage in real-time.
The PCF that uses usage monitoring for making dynamic policy decisions shall set and send the applicable thresholds to the SMF for monitoring. The usage monitoring thresholds shall be based either on time, or on volume. The PCF may send both thresholds to the SMF. The SMF shall notify the PCF when a threshold is reached and report the accumulated usage since the last report for usage monitoring. If both time and volume thresholds were provided to the SMF, the accumulated usage since last report shall be reported when either the time or the volume thresholds are reached.
NOTE:
There are reasons other than reaching a threshold that can cause the SMF to report accumulated usage to the PCF as defined in clauses 6.2.2.3.
The usage monitoring capability shall be possible for an individual or a group of service data flow(s), or for all traffic of a PDU Session in the SMF. When usage monitoring for all traffic of a PDU Session is enabled, it shall be possible to exclude an individual SDF or a group of service data flow(s) from the usage monitoring for all traffic of this PDU Session. It shall be possible to activate usage monitoring both to service data flows associated with predefined PCC rules and dynamic PCC rules, including rules with deferred activation and/or deactivation times while those rules are active.
If service data flow(s) need to be excluded from PDU Session level usage monitoring and PDU Session level usage monitoring is enabled, the PCF shall be able to provide the an indication of exclusion from session level monitoring associated with the respective PCC rule(s).
It shall be possible to apply different usage monitoring depending on the access used to carry a Service Data Flow.
Up
4.3.5  Application detection and control requirements
The application detection and control feature comprise the request to detect the specified application traffic, report to the PCF on the start or stop of application traffic and to apply the specified enforcement and charging actions.
The PCF shall instruct the SMF on which applications to detect and whether to report start or stop event to the PCF by activating the appropriate PCC rules in the SMF. Reporting notifications of start and stop of application detection to the PCF may be muted.
The report to the PCF shall include the report is for start or stop, the detected application identifier and, if deducible, the service data flow descriptions for the detected application traffic.
Upon receiving the report from SMF, the PCF may make policy decisions based on the information received and may send the corresponding updated or new PCC rules to the SMF.
In this release of the specification Application Detection and Control applies only to the IP PDU Session types.
Up
4.3.6  Support for session management related network capability exposureWord-p. 17
Support for network capability exposure enables an AF (e.g. an external ASP) to request the following session management related policy control functionality from the NEF:
Up
4.3.7  Traffic steering control
Traffic Steering Control refers to the capability to activate/deactivate traffic steering policies from the PCF in the SMF for the purpose of:
  • steering the subscriber's traffic to appropriate operator 3rd party service functions (e.g. NAT, antimalware, parental control, DDoS protection) in the N6-LAN or 5G-LAN type of services. This is supported in non-roaming and home-routed scenarios only.
  • AF influenced traffic diversion which enables the routing of the user traffic matching the traffic filters provided in the PCC rule to a local Data Network identified by the DNAI per AF request. This is supported in non-roaming and LBO scenarios only, as described in TS 23.501, clause 5.6.7.
Up

Up   Top   ToC