Content for  TS 33.128  Word version:  18.7.0

When interception of communication contents is authorised or the delivery of packet header information is authorised and approach 2 described in clause 6.2.3.5 is used, the CC-TF present in the SMF sends a trigger to the CC-POI present in the UPF over the LI_T3 interface. When the CC-TF in the SMF detects that a PDU session is being established (i.e. when the SMF sends the N4: PFCP Session Establishment Request to the UPF, see clause 6.3.2 of TS 29.244) for a target UE, it shall send an activation message to the CC-POI in the UPF over the LI_T3 interface. The activation message shall contain the correlation identifiers that the CC-POI in the UPF shall use with the xCC. This can be achieved by sending an ActivateTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.1 with the following details.

The CC-TF in the SMF shall not send the ListOfServiceTypes parameter of the ActivateTask message to the CC-POI in the UPF.

When the CC-TF in the SMF detects that a targeted PDU session is changing (i.e. when the SMF sends the N4: PFCP Session Modification Request to the UPF, see clause 6.3.3 of TS 29.244) in a way that requires changes to the interception already activated by the CC-POI in the UPF, the CC-TF shall modify the interception at the CC-POI in the UPF over the LI_T3 interface. This is achieved by sending a ModifyTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.2. The ModifyTask message contains the same details as the ActivateTask message with the following fields updated as appropriate.

When the CC-TF in the SMF detects that a targeted PDU session is changing (i.e. when the SMF sends the N4: PFCP Session Modification Request to the UPF) for which the interception had not been previously activated in the CC-POI in the UPF (e.g. in case of previous unsuccessful LI activation at the CC-POI in the UPF by the CC-TF in the SMF), the CC-TF shall send an activation message to the CC-POI in the UPF over the LI_T3 interface. The activation message shall contain the correlation identifiers that the CC-POI in the UPF shall use with the xCC. This can be achieved by sending an ActivateTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.1 with the details provided by Table 6.2.3-6. When the CC-TF in the SMF detects that the PDU session has been released (i.e. when the SMF sends the N4: PFCP Session Deletion Request to the UPF, see clause 6.3.4 of TS 29.244) for a target UE, it shall send a deactivation message to the CC-POI in the UPF over the LI_T3 interface. When using ETSI TS 103 221-1 [7] this is achieved by sending a DeactivateTask message with the XID field set to the XID associated with the interception, as described in ETSI TS 103 221-1 [7] clause 6.2.3. By default, interception shall occur at the anchor UPF as described in clause 6.2.3.3.3. When a warrant that includes the service scoping of CC is activated for a target UE with an established PDU session and when the IRI-POI present in the SMF generates the xIRI containing an SMFStartOf­Interception­WithEstablished­PDUSession record (see clause 6.2.3.2.5), the CC-TF present in the SMF shall send an activation message to the CC-POI present in the UPF to generate the xCC.

When a target UE accesses multiple Data Networks (DNs) via a multi-homed PDU session (see clause 5.6.4.3 of TS 23.501), multiple UPFs are involved in providing the PDU Session Anchors, with one UPF providing the Branching Point functionality. The Branching Point UPF may, or may not, be a PDU Session Anchor UPF (see TS 33.127 Annex A.3.2). The CC-TF present in the SMF shall send the CC intercept trigger to the CC-POI present in an UPF if and only if that UPF is selected to provide the CC-POI functions. When the target UE is involved in multi-homed PDU session, the CC-TF present in the SMF (i.e. in the SMF that establishes the PDU session) shall determine which UPF(s) is(are) more suitable to provide the CC-POI functions adhering to the following requirements specified in TS 33.127:

• All applicable user plane packets are captured and delivered.
• Duplicate delivery of CC is suppressed to the extent possible.

This clause assumes that a PDU session contains only one Branching Point UPF (with N3 reference point toward the target UE) and one PDU Session Anchor UPF for each DN connection. Since the present document requires the interception of all DN connections, the SMF may choose either all the PDU Session Anchor UPFs or the Branching Point UPF to provide the CC-POI functions. The Branching Point UPF may be chosen when all user plane packets pass through the Branching Point UPF, and the CC-TF present in the SMF may choose the Branching Point UPF to provide the CC-POI function and accordingly, send the CC interception trigger to the CC-POI present in the Branching Point UPF. The CC intercept trigger shall include the packet detection rules. An example of these rules is:

• Generate the xCC from all the incoming and outgoing user plane packets to the target UE.

In this case, the CC-TF present in the SMF shall not select any of the PDU Session Anchor UPFs to provide the CC-POI functions. When a Branching Point UPF is chosen to provide the CC-POI functions, and if the Branching Point UPF is removed from the user plane path during a PDU session, then the CC POI functions will have to be moved to the PDU Session Anchor UPFs. The xCC delivered to the MDF3 shall be correlated to the PDU session related xIRI. The use of Correlation Id shall be on a user-plane path basis, which means that the xCC generated at different UPFs that belong to different PDU sessions may need to have separate Correlation IDs, each correlating to their own PDU session related xIRI.

An option is to intercept a copy of the packets sent and received on the N6 interface [2] side of the PDU Anchor UPF (for each UL classifier in case of selective routing or Service and Session Continuity mode 3) for all DNs the subject is connected to. In the in-bound roaming case for home-routed roaming, the CSP shall deliver a copy of the packets sent and received on the N9 side of the PDU Anchor UPF towards the serving network.

When packet header information reporting is authorised, packet header information reports are generated either by the IRI-POI in the UPF (if approach 1 from clause 7.12.2.3 of TS 33.127 is used) or by the MDF2 (if approach 2 from clause 7.12.2.3 of TS 33.127 is used). Depending on the requirements of the warrant, the packet header information reports can be in per-packet form, as Packet Data Header Reports (PDHRs), or in summary form, as Packet Data Header Summary Reports (PDSRs).

If the IRI-POI in the UPF is placed on a link which fragmented the original IP packet (see RFC 791 for basic fragmentation rules, and RFC 815 for more complex re-assembly rules), a situation may occur in which only the first fragment can be sensibly reported in a PDHR, while the subsequent fragments may be missing essential fields that are mandatory, which may cause simplistic implementations to mis-report them, or omit them altogether. In this case, the IRI-POI in the UPF shall report the first fragment of a fragmented IP packet, including the port numbers when they are included within this first fragment, using the length of the fragment to determine if the port numbers are indeed encoded within this first fragment. The subsequent fragments are reported without port information. This technique relieves the IRI-POI in the UPF from having to reassemble the original IP packet (at line speed) at the cost of accuracy of the reported fields.

If the per-packet form of packet header information reporting, i.e. PDHR, is authorised, the PDHeaderReport xIRI shall be generated as described in clause 6.2.3.9.3.

If the summary form of the packet header information reporting, i.e. PDSR, is authorised, the PDSummaryReport xIRI shall be generated as described in clause 6.2.3.9.4.

As described in clause 7.12.2 of TS 33.127, warrants that do not require the interception of communication contents but do require packet header information reporting will require access to the user plane packets. Packet header information reporting includes the following two IRI messages:

• Packet Data Header Reporting (PDHR) in the form of PDHeaderReport records.
• Packet Data Summary Reporting (PDSR) in the form of PDSummaryReport records.

clause 7.12.2 of TS 33.127 provides two approaches for the generation of such IRI messages. In approach 1, the IRI-POI present in the UP Entityconstructs and delivers the packet header information reporting related xIRIs to the MDF2 as described in clause 6.2.3.4. In approach 2, the CC-POI present in the UP Entity intercepts, constructs and delivers the xCC to the MDF3 as described in clause 6.2.3.6. The MDF3 forwards the xCC to the MDF2 over the LI_MDF interface and the MDF2 generates the IRI messages containing the packet header information reporting related records from the xCC. In both approaches, the payload of the PDHeaderReport and PDSummaryReport records are as described in clauses 6.2.3.9.3, 6.2.3.9.4, Table 6.2.3.9.3-1 and Table 6.2.3.9.4-1. Note that in approach 2, the MDF2 generates these IRI messages containing PDHeaderReport and PDSummaryReport records without receiving the equivalent xIRI from an IRI-POI. The actions of the MDF2, the MDF3, the CC-TF in the CP Entity in 5GS and CUPS EPS, and the CC-POI in non-CUPS EPS are managed as part of the intercept data provisioned to them over the LI_X1 interface.

Table 6.2.3.9.2-1 shows the details of the HeaderReporting TaskDetailsExtension used in the LI_X1 ActivateTask message used for provisioning LI functions when packet header information reporting is authorised.

If the per-packet form of packet header information reporting, i.e. PDHR, is used, the LI function responsible for generating the xIRI extracts the information shown in Table 6.2.3.9.3-1 from each packet.

If the summary form of the packet header reporting, i.e. PDSR, is used, the LI function responsible for generating the xIRI extracts the information shown in Table 6.2.3.9.4-1 from each packet and aggregates it in summaries according to the pDSRType field defined in the PDHRReportingExtensions parameters of the ActivateTask message used to provision the LI function. In addition, the current summary is sent when the LI function responsible for generating the xIRI receives a DeactivateTask message for the Task that generated the PDSR regardless of whether the trigger in the pDSRType field of the ActivateTask message was met. In this case, the pDSRSummaryTrigger field of the PDSR record shall be set to endOfFlow. A PDSR shall be generated each time a flow (Source IP, Source Port, Destination IP, Destination Port, Next Level Protocol, Direction) starts or ends. If the useSessionTriggers flag (see Table 6.2.3.9.2-2) is absent or set to false and the provisioned pDSRTriggerType is:

• Packet count, a PDSR shall be generated whenever the number of packets detected as a part of the flow reaches the provisioned trigger value.
• Byte count, a PDSR shall be generated whenever the value for the cumulative byte size across all packets belonging to the flow reaches the provisioned trigger value.
• Timer expiry, a separate timer should be used for each flow. A PDSR shall be generated for a flow whenever the timer for that flow expires.

If the useSessionTriggers flag (see Table 6.2.3.9.2-2) is set to true and the provisioned pDSRTriggerType is:

• Packet count, a PDSR shall be generated for each open flow whenever the number of packets sent and received in the PDU Session/PDN Connection is reaches the provisioned trigger value.
• Byte count, a PDSR shall be generated for each open flow whenever the value for the cumulative byte size across all packets belonging to the PDU Session/PDN Connection is reaches the provisioned trigger value.
• Timer expiry, a single timer should be used for each PDU Session/PDN Connection. A PDSR shall be generated for each open flow whenever the timer expires.

TFs in SMFs in SMF sets need to share LI state information to avoid losing track of the XIDs and CorrelationIDs used in the tasks activated in the POI in the UPF when the triggered task control is transferred from one TF to another. POIs in SMFs in SMF sets need to share LI state information to avoid losing track of the CorrelationIDs and sequence numbers used in the generation of xIRI and xCC when the interception is moved to another POI in the same SMF set. The LIPF may request, store or remove any LI state records at any moment. The LIPF may revoke the credentials of any LI function to use the LI_ST function via LI_X0.

The TF in the SMF shall store the LI state (related to a task active in the UPF POI) in the LISSF whenever the parent SMF stores session state for the relevant PDU session in the UDSF and whenever the parent SMF sends session state for the relevant PDU session to another SMF. The POI in the SMF shall store the LI state (related to a task active in the SMF POI) in the LISSF whenever the parent SMF stores session state for the relevant PDU session in the UDSF and whenever the parent SMF sends session state for the relevant PDU session to another SMF. When storing state, the LI function in the SMF shall use the state storage procedure specified in clause 5.10.2. During this procedure, the LI function shall add the metadata shown in Table 6.2.3.10.2-1 to the RecordMeta for the record.

The TF shall store the following information as the first record block (see clause 6.1.3.3.3.2 of TS 29.598), encoded as XML following the XSD schema given in Annex H.

The TF shall specify the XID in order to avoid removing the LI state related to the same ProductID but a different task in the UPF POI, for example if there is more than one PDU session. The SMF POI shall store the information shown in Table 6.2.3.10.2-4 as the first record block (see clause 6.1.3.3.3.2 of TS 29.598), encoded as XML following the XSD schema given in Annex H.

When the TF in an SMF in an SMF set is provisioned by the LIPF with a specific XID and access to an LISSF function, the TF shall use the LISSF to retrieve LI state information. If the implementation of the SMF set does not ensure that active SM contexts are always present in some SMF of the SMF set, when a task previously provisioned by the LIPF in the TF is deactivated, the TF shall request the records associated to the XID (received from the LIPF) from the LISSF, by performing a search as described in clause 5.10.3, using the XID as a search criteria. If no records are found, the TF may assume that no previous interception has occurred and proceed accordingly. When a TF detects that its parent SMF is retrieving state for a targeted PDU session from the UDSF, the TF shall request records associated with that PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the UDSFRecordID used by the SMF as a search criteria. When a TF detects that its parent SMF is receiving state for a targeted PDU session from another SMF, the TF shall request records associated with that PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the XID of the task related to the target of that PDU session. If no records are found, the TF may assume that no previous interception has occurred and proceed accordingly. Implementers should be aware that multiple records may be returned. When an SMF POI detects that its parent SMF is retrieving state for a targeted PDU session from the UDSF, the POI shall request records associated with that PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the UDSFRecordID used by the SMF as a search criteria. When an SMF POI detects that its parent SMF is receiving state for a targeted PDU session from another SMF, the SMF POI shall request records associated with that target PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the XID of the task related to the target of that PDU session. If no records are found, the SMF POI may assume that no previous interception has occurred and proceed accordingly.

When a task is deactivated successfully in the UPF POI, the TF shall remove the LI state record from the LISSF as described in clause 5.10.4. When a task is deactivated in the SMF POI, the POI shall remove the LI state record from the LISSF as described in clause 5.10.4.