In this Release of the specification, in order to support IPTV services, following principles apply:
the 5G-RG supports IP PDU Session Type;
IP multicast traffic received from N6 interface is replicated by UPF and sent over PDU Sessions;
IGMP or MLD messages from the STB or from the 5G-RG are terminated and managed by the UPF acting as PSA;
IGMPv2 specified in RFC 2236, IGMPv3 specified in RFC 4604, for MLDv1 specified in RFC 2710 and MLDv2 specified in RFC 4604 are supported
The SMF controls the support of IPTV by the UPF acting as PSA using PDR, FAR, QER, URR. This includes control of which IGMP and MLD requests the UPF is to accept or to deny.
This clause describes the procedures that support IPTV in 5G system including the procedures below:
Registration and PDU Session Establishment procedure for IPTV is shown in clause 7.7.1.1.1. The Registration Procedure is used to register to 5GS and the PDU Session Establishment Procedure is used to establish the PDU Session used for IPTV Service.
IPTV Access procedure shown in clause 7.7.1.1.2 may, depending on the deployment, be used to access the IPTV network, e.g. completing the IPTV Authentication and IP allocation.
Unicast/Multicast Packets transmission procedure shown in clause 7.7.1.1.3. The procedure specifies how to transmit unicast/multicast packets related with IPTV service over 5GC.
In this Release of the specification, the 5GC does not assume any traffic replication capability in the 5G AN (NG-RAN or W-5GAN).
5G-RG perform PDU Session establishment procedure described in clause 4.3.2.2.1 of TS 23.502 applies with the following differences and clarifications:
UE is replaced by 5G-RG.
In step 1 of clause 4.3.2.2.1 of TS 23.502, 5G-RG may indicate within the Protocol Configuration Options element that the UE requests to obtain the IPv4 address with DHCPv4.
5G-RG shall establish an IP-based PDU Session with a specific (DNN, S-NSSAI) for IPTV service.
The SMF sends to the UPF acting as PSA N4 rules such as PDR, FAR related to IP Multicast traffic allowed for the PDU Session. This may take place at steps 10a and 16a of clause 4.3.2.2.1 of TS 23.502. Such N4 rules are further described in clause 4.6. IP Multicast traffic allowed for the PDU Session corresponds to IPTV services allowed for the user.
In the case of IPTV network access control based on the DHCP procedure, 5G-RG may be configured to retrieve via DHCP the IP address that it will use to access IPTV services. The DHCP procedure described in clause 5.8.2.2 of TS 23.501 is carried out with the difference shown below:
When the SMF receives the Uplink DHCP message, the SMF may be configured to insert the IPTV access control information as received in subscription data from UDM to the uplink DHCP message.
5GS can support Unicast Service from IPTV network directly.
In order to obtain the multicast service from IPTV network, the Multicast Packets transmission procedure should be performed. The procedure in Figure 7.7.1.1.3-1 describes how the 5G-RG joins an IP multicast group.
When UPF receives the IGMP or MLD Join, the UPF may identify IGMP and MLD packets based on PDR received over N4 as described in clause 4.6 and handle the IGMP and MLD Join accordingly based on FAR as described in clause 4.6. An example is given as below:
If the IP Multicast Addressing information included in the IGMP or MLD Join message is allowed to be accessed via the PDU Session , the UPF shall add the PDU Session to the requested multicast group. If requested by an URR, the UPF notifies the SMF that the UE is joining to a multicast group, providing the associated IP Multicast Addressing information.
If the IP Multicast Addressing information included in the IGMP or MLD Join message is not allowed to be accessed via the PDU Session, the UPF shall not add the PDU Session to the requested multicast group.
The UPF acts as a Multicast Router as defined in RFC 2236, RFC 4604 and RFC 2710. This may include following actions:
if the IGMP or MLD Join message is the first IGMP or MLD request the UPF has received about the target IP multicast traffic: the UPF exchanges N6 signalling such as PIM (Protocol-Independent Multicast) in order to connect to the N6 multicast distribution tree related with this IP multicast traffic; This ensures that the UPF receives the DL multicast traffic.
The IP multicast related signalling protocol used on N6 (e.g. Sparse Mode PIM-SM) to be supported over N6 is defined by local policies on the UPF.
if the SMF had set the corresponding URR Reporting trigger with a value "IP multicast join/leave" (as defined in clause 4.6.5), the UPF issues an UPF report to the SMF and the corresponding IP Multicast addressing information
if the PCF had set the corresponding Policy Control Request Trigger set to "UE join to a multicast group" trigger (as defined in clause 9.7), the SMF issues a SMF initiated SM Policy Association Modification (as defined in clause 4.16.5 of TS 23.502) reporting to the PCF the corresponding IP Multicast addressing information.
When the UPF receives IP multicast packets from multicast server in IPTV network, the UPF select the PDU Session(s) where to transmit the multicast packets based on the multicast group, constructed in step 2 and fulfilling the FAR and QER rules described in clause 7.7.1.1.1.
The 5G-RG may leave the IP Multicast Group as follows:
sending an unsolicited IGMP Leave or MLD Done message;
IGMPv2 Leave message or a IGMPv3 Membership Report with indication of State Change Record or MLD Done message to request to leave a specific IP Multicast Group. The Message may be solicited by UPF via an IGMP MLD Query message.
The 5G-RG may send a IGMP or MLD Membership Report message where the address of a IP Multicast Group is no more included in the list. This message may be the answer to the query in step 1a or it may be sent unsolicited.
The 5G-RG may send an IGMPv2 Leave message or a IGMPv3 Membership Report with indication of State Change Record or MLD Done message to request to leave a specific IP Multicast Group.
When UPF receives the IGMP or MLD message in step 1b or 1c the UPF may identify the IGMP and MLD packets based on PDR received over N4 as described in clause 4.6.3 and handle the IGMP and MLD message accordingly as below:
If the IP Multicast Addressing information included in the IGMP or MLD Report message does not include the IP address(es) of a multicast group the UPF stop forwarding the packet to the 5G-RG.
if the UPF receives an IGMP Leave or MLD Done message, the UPF stops forwarding multicast packets related to the IP multicast Group to the 5G-RG.
The UPF acts as a Multicast Router as defined in RFC 2236, RFC 4604 and RFC 2010. This may include following actions:
the UPF may exchange N6 signalling such as PIM (Protocol-Independent Multicast) in order to leave a IP multicast Group if no other 5G-RG are connected to the same IP multicast Group; This ensures that the UPF does no more receive the DL multicast traffic, if not needed.
The IP multicast related signalling protocol used on N6 (e.g. Sparse Mode PIM-SM) to be supported over N6 is defined by local policies on the UPF.
if the SMF had set the corresponding URR Reporting trigger with a value "IP multicast join/leave" (as defined in clause 4.6.5), the UPF issues an UPF report to the SMF the corresponding IP Multicast addressing information
if the PCF had set the corresponding Policy Control Request Trigger set to "UE join to a multicast group" trigger, the SMF issues a SMF initiated SM Policy Association Modification (as defined in clause 4.16.5 of TS 23.502) reporting to the PCF the corresponding IP Multicast addressing information.
To create a new request, the AF invokes an Nnef_IPTV_configuration service operation. The request contains the Multicast Access Control List, a GPSI or an External Group Id, AF Transaction Id, application identifier and may contain a DNN and/or a S-NNSAI. To update or remove an existing request, the AF invokes Nnef_IPTV_configuration_Update or Nnef_IPTV_configuration_Delete service operation providing the corresponding AF Transaction Id.
The AF sends its request to the NEF. The NEF ensures the necessary authorization control, including throttling of AF requests and, as described in clause 4.3.6.1 of TS 23.502, mapping from the information provided by the AF into information needed by the 5GC.
(in the case of Nnef_IPTV_configuration_Create or Update): The NEF stores the AF request information in the UDR (Data Set = Application Data; Data Subset = IPTV_configuration, Data Key = AF Transaction Internal ID, S-NSSAI and DNN and/or SUPI/Internal-Group-Id).
(in the case of Nnef_IPTV_configuration_Delete): The NEF deletes the AF requirements in the UDR (Data Set = Application Data; Data Subset = IPTV_configuration, Data Key = AF Transaction Internal ID).
The NEF responds to the AF.
The PCF(s) that have subscribed to modifications of AF requests (Data Set = Application Data; Data Subset = IPTV_configuration, Data Key = SUPI/Internal-Group-Id) receive a Nudr_DM_Notify notification of data change from the UDR.
The PCF determines if existing PDU Sessions are potentially impacted by the AF request. For each of these PDU Sessions, the PCF updates the SMF with corresponding new PCC rule(s) by invoking Npcf_SMPolicyControl_UpdateNotify service operation as described in steps 5 and 6 in clause 4.16.5 of TS 23.502.
Table 7.7.1.1.4-1 shows an example of a Multicast Access Control list provided by the AF in the IPTV domain to the NEF. The Multicast Access Control List defines the access right status (i.e. fully allowed, preview allowed, not allowed) of each of the Multicast channels per subscriber identified by a GPSI.
IP Multicast Addressing information 1 (related to Channel 1)
IP Multicast Addressing information 2 (related to Channel 2)
IP Multicast Addressing information 3 (related to Channel 3)
GPSI 1
Fully allowed
Not allowed
Preview allowed
The NEF maps the GPSI into the SUPI, assigned to a 5G-RG, as described in step 2 in Figure 7.7.1.1.4-1. and stores the Multicast Access Control List in the UDR as shown in Table 7.7.1.1.4-2.
IP Multicast Addressing information 1 (related to TV Channel 1)
IP Multicast Addressing information 2 (related to TV Channel 2)
IP Multicast Addressing information 3 (related to TV Channel 3)
SUPI for 5G-RG 1
Fully allowed
Not allowed
Preview allowed
SUPI for 5G-RG 2
Fully allowed
Fully allowed
Not allowed
SUPI for 5G-RG 3
Fully allowed
Preview allowed
Preview allowed
If source Specific Multicast is to be used for a TV Channel, IP Multicast Addressing information corresponds to IP Multicast address and Source IP address.
The PCF is assumed to have subscribed to relevant modifications of that UDR data defined in the Table 7.7.1.1.4-2.