D.1 DOCSIS IP‑CAN
23.2033GPPPolicy and charging control architectureRelease 17TS
D.1.1 General
In the DOCSIS IP‑CAN, each UE is connected to the network via a Cable Modem (CM) which is connected through a Hybrid Fibre Coax (HFC) access network to a Cable Modem Termination System (CMTS). Though the UE and CM may or may not be embedded within the same physical package, they remain separate logical devices. One or more UEs may subtend a single CM. Because the CMTS provides the IP connectivity and traffic scheduling and manages quality of service for the CM and the UEs which subtend it, the CMTS fulfils the role of PCEF for the DOCSIS IP‑CAN. In the DOCSIS IP‑CAN, the Application Manager (AM) and the Policy Server (PS) fulfil the role of the PCRF.
When accessing resources via a DOCSIS IP‑CAN, the Rx interface can be used to request resources. The communication between the AM and PS and the PS and CMTS uses the PKT-MM-2 interface which is based on COPS and defined in J.179. The remainder of this clause documents the mapping of PCC terminology to the DOCSIS IP‑CAN and how the DOCSIS IP‑CAN realizes the defined PCC functionality. This clause also establishes the requirements of the Rx interface as it is used for the DOCSIS IP‑CAN.
The PKT-MM-2 interface is shown here for information to illustrate the organization of the DOCSIS IP‑CAN. References that specify the PKT-MM-2 interface do not constitute normative requirements for the 3GPP architecture. The DOCSIS IP‑CAN does not intend to pose any new normative requirements for the Gx interface.
Figure D.1.1: DOCSIS IP‑CAN
D.1.1 High level requirements
D.1.1.1 General
The DOCSIS IP‑CAN employs for an IP‑CAN session, the concept of a DOCSIS registration.
The DOCSIS IP‑CAN employs for an IP‑CAN bearer, the concept of a DOCSIS service flow in order to provide an information path between the UE and the CMTS. Note that DOCSIS service flows are unidirectional, either upstream (toward the CMTS) or downstream (toward the CM). When a CM is registered in the DOCSIS IP‑CAN, it is assigned a unique IP Address and separate primary service flows are created for both the upstream and downstream direction These primary service flows are typically given best effort scheduling and are used to carry all IP traffic through the CM for which a more specific service flow has not been created. When a UE is registered in the DOCSIS IP‑CAN, it is assigned its own IP Address and is identified by its MAC address. A UE does not have a service flow assigned to it as a result of registration; rather it is associated with the primary service flows of the CM through which it is attached to the network. Additional bearers for the UE are created dynamically as required to provide appropriate QoS for service flows.
Bearer creation is triggered when media descriptors (Media Type and Format) for the SIP session are sent from the AF to the AM over the Rx interface. The AM translates the media descriptors into a QoS request for a DOCSIS service flow. The AM then forwards the QoS request towards the bearer enforcement point using the PKT-MM-2 interface. The PKT-MM-2 interface is not a 3GPP reference point, Specifications that detail the PKT-MM-2 interface do not impose normative requirements on the 3GPP architecture.
The following figure provides a graphical representation of the DOCSIS IP‑CAN and how it maps into the generic PCC terminology.
Figure D.1.2: PCC to DOCSIS terminology mapping
The DOCSIS IP‑CAN defines an IP-Flow to be a unidirectional sequence of packets identified by OSI Layer 3 and Layer 4 header information. This information includes source/destination IP addresses, source/destination port numbers, protocol ID. Multiple Multimedia streams may be carried in a single IP Flow.
In a DOCSIS IP‑CAN, there is no equivalent concept as a service data flow. Further a DOCSIS service flow is uni-directional and each service flow is an aggregation of the QoS needs for all the IP-Flows which make up the service flow. As such, the QoS enforcement is done at the service flow level not at the IP-Flow level.
D.1.1.2 Charging related requirements
D.1.1.3 Policy control requirements
D.1.2 Architecture model and reference points
D.1.2.1 Reference points
D.1.2.1.1 Rx reference point
D.1.2.1.2 Gx reference point
D.1.2.1.3 Void
D.1.3 Functional description
D.1.3.1 Overall description
The DOSCIS IP‑CAN employs for an IP‑CAN bearer, the concept of a DOCSIS service flow in order to provide an information path between the UE and the CMTS. When a Cable Modem is registered in the DOCSIS IP‑CAN, primary upstream and downstream service flows are created.
When a UE is registered in the DOCSIS IP‑CAN it is associated with the primary service flows of the cable modem through which it is attached to the network. Based on session information provided by the AF using the Rx reference point, the Application Manager will determine QoS requirements for each IP flow. IP flows which do not require special quality of service treatment may be carried over the primary service flows. For other IP flows which require specific QoS treatment, the Policy Server requests the CMTS to admit the flows using the pkt-mm-2 interface providing detailed information of the QoS requirements. Provided that resources are available, the CMTS will create additional bearers dynamically and push the appropriate traffic filters to the cable modem.
D.1.3.1.1 Binding mechanism
In the DOCSIS IP‑CAN, the binding mechanism is achieved through the use of traffic Classifiers. These Classifiers filter traffic destined to a UE behind a Cable Modem or sourced from a UE behind a Cable Modem, to a particular DOCSIS service flow. DOCSIS Classifiers contain the following attributes which can be used to filter IP traffic:
– IP Type of Service – Range and Mask;
– IP Protocol;
– IP Source Address;
– IP Source Mask;
– IP Destination Address;
– IP Destination Mask;
– TCP/UDP Source Port Start;
– TCP/UDP Source Port End;
– TCP/UDP Destination Port Start;
– TCP/UDP Destination Port End.
The Classifier(s) which are used for a particular DOCSIS service flow are communicated to the CMTS by the Policy Server (on behalf of the Application Manager) via the pkt-mm-2 interface. The Application Manager will specify the QoS requirements for the IP flow, the direction of the IP flow, and the Classifier(s) which are to be used for the DOCSIS service flow serving the IP flow.
When a session is no longer in use, the Application Manager communicates to the CMTS to tear down the resources associated with the session. Based on this communication, the CMTS will remove the DOCSIS service flow(s) and any Classifier(s) associated with the service flow(s), and inform the Cable Modem of the removal. Traffic which previously matched the removed Classifier(s) will now be placed on either the upstream or downstream primary DOCSIS service flow, depending on the direction of the traffic.
D.1.3.2 Functional entities
D.1.3.2.1 Policy Control and Charging Rules Function (PCRF)
In the DOCSIS IP‑CAN, the Application Manager (AM) and the Policy Server (PS) fulfil the role of the PCRF.
The AM receives media descriptors (Media Type and Format) from the AF for SIP sessions and maps the QoS needs of the session to a FlowSpec, The FlowSpec is a layer 2 independent representation of the bandwidth and QoS requirements for the flow derived from the media descriptors using a well defined algorithm. The AM and PS provide network resource control in the DOCSIS IP‑CAN by managing the CMTS using the PacketCable Multimedia interface pkt-mm-2.
The AM and PS map IP flows to DOCSIS service flows in accordance with the operator’s policies and based on the media format information provided by the AF.
D.1.3.2.1.1 Input for PCC decisions
The AM accepts any of the following input as a basis for decisions on PCC rule operations:
– Per IP‑CAN session (e.g.: UE IP address);
– Requested QoS, media format, priority indicator.
The SPR may provide the following information:
– Subscribers maximum allowed QoS resources.
Subscriber’s maximum allowed bit rate for upstream and downstream.
D.1.3.2.2 Policy and Charging Enforcement Function (PCEF)
The CMTS provides PCEF equivalent functionality within the DOCSIS IP‑CAN. The CMTS creates, modifies, and deletes DOCSIS service flows upon request of the Policy Server. The CMTS receives requests from the Policy Server over the pkt-mm-2 interface.