Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.127  Word version:  18.6.0

Top   Top   Up   Prev   Next
0…   5…   5.4…   5.6…   5.7…   6…   6.2.2…   6.2.3…   6.2.5…   6.3…   6.3.3…   6.3.4…   6.4…   7…   7.3…   7.4…   7.4.7…   7.5…   7.6…   7.7…   7.8…   7.9…   7.10…   7.11…   7.12…   7.13…   7.14…   7.15…   7.16…   8…   A…   A.2…   A.3…   A.4…   B…   D…   E…

 

6.2.3  LI for SMF/UPFp. 48

6.2.3.1  Architecturep. 48

In the 5GC network, user plane functions are separated from the control plane functions. The SMF that handles control plane actions (e.g. establishing, modifying, deleting) for the PDU sessions shall include an IRI-POI that has the LI capability to generate the related xIRI. The UPF that handles the user plane data shall include a CC-POI that has the capability to duplicate the user plane packets from the PDU sessions based on the interception rules received from the SMF. Figure 6.2-4 shows the LI architecture for SMF/UPF based interception.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 6.2-4: LI architecture showing LI at SMF/UPF
Figure 6.2-4: LI architecture showing LI at SMF/UPF
(⇒ copy of original 3GPP image)
Up
The LICF present in the ADMF receives the warrant from an LEA, derives the intercept information from the warrant and provides it to the LIPF.
The LIPF present in the ADMF provisions IRI-POI (present in the SMF), MDF2 and MDF3 over the LI_X1 interfaces. To enable the interception of the target's user plane packets (e.g. when the warrant requires the interception of communication contents), the CC-TF present in the SMF is also provisioned with the intercept data.
The LIPF may interact with the SIRF (over LI_SI) present in the NRF to discover the SMFs and UPFs in the network. The IRI-POI present in the SMF detects the PDU session establishment, modification, and deletion related events, generates and delivers the related xIRI to the MDF2 over LI_X2. The MDF2 delivers the IRI messages to the LEMF over LI_HI2.
When interception of communication contents is required, the CC-TF present in the SMF sends a trigger to the CC-POI present in the UPF over the LI_T3 interface. The CC-POI in the UPF shall present itself as the same CC-POI to all the CC-TFs in the same SMF set, such that a CC-TF is capable of modifying or deactivating a task activated/modified in the CC-POI by a different CC-TF in the same SMF set.
The trigger sent from the CC-TF to CC-POI includes the following information:
  • User plane packet detection rules.
  • Target identity.
  • Correlation information.
  • MDF3 address.
The CC-POI present in the UPF generates the xCC from the user plane packets and delivers the xCC (that includes the correlation number and the target identity) to the MDF3. The MDF3 delivers the CC to the LEMF over LI_HI3.
A warrant that does not require the interception of communication contents, may require IRI messages that have to be derived from the user plane packets. To support the generation of related xIRI (i.e. that requires access to the user plane packets), the present document supports two implementation approaches as described in clause 7.12.2. When approach 1 from clause 7.12.2 is used, the IRI-POI in the UPF shall present itself as the same IRI-POI to all the IRI-TFs in the same SMF set, such that an IRI-TF is capable of modifying or deactivating a task activated/modified in the IRI-POI by a different IRI-TF in the same SMF set.
Clause 8.6.2 defines a CC-PAG (CC-POI Aggregator) as an architectural extension option that is located between the MDF3 and CC-POI and performs the function of aggregating the xCC from different CC-POIs towards the MDF3.
Up

6.2.3.2  Target identitiesp. 49

The LIPF provisions the intercept related information associated with the following target identities to the IRI-POI present in the SMF:
  • SUPI.
  • PEI.
  • GPSI.
The interception performed on the above three identities are mutually independent, even though, an xIRI may contain the information about the other identities when available.

6.2.3.3  IRI eventsp. 49

The IRI-POI present in the SMF shall generate xIRI, when it detects the following specific events or information:
  • PDU session establishment.
  • PDU session modification.
  • PDU session release.
  • Start of interception with an established PDU session.
The PDU session establishment xIRI is generated when the IRI-POI present in the SMF detects that a PDU session has been established for the target UE.
The PDU session modification xIRI is generated when the IRI-POI present in the SMF detects that a PDU session is modified for the target UE.
The PDU session release xIRI is generated when the IRI-POI present in the SMF detects that a PDU session is released for the target UE.
The start of interception with an established PDU session xIRI is generated when the IRI-POI present in a SMF detects that interception is activated on the target UE that has an already established PDU session in the 5GS. When a target UE has multiple PDU sessions, this xIRI shall be sent for each PDU session with a different value of correlation information.
When additional warrants are activated on a target UE, MDF2 shall be able to generate and deliver the start of interception with an established PDU session related IRI messages to the LEMF associated with the warrants without receiving the corresponding start of interception with an established PDU session xIRI.
When the warrant requires the packet header information reporting, the following xIRI shall be generated:
The generation of packet header information reporting can be done by either the IRI-POI present in the UPF or the MDF2.
Up

6.2.3.4  Common IRI parametersp. 50

The list of xIRI parameters are specified in TS 33.128. Each xIRI shall include at the minimum the following information:
  • Target identity.
  • Time stamp.
  • Correlation information.
  • Location information.
  • Session related information.

6.2.3.5  Specific IRI parametersp. 50

The parameters in each xIRI are defined in TS 33.128.

6.2.3.6  Network topologiesp. 50

The SMF shall provide the IRI-POI functions in the following network topology cases:
  • Non-roaming case.
  • Roaming case, in VPLMN.
  • Roaming case, in HPLMN.
  • Non-3GPP access case, in the PLMN where N3A Entity resides.
When the target UE has multiple PDU sessions active, the generation and delivery of xCC for each PDU session shall be done independently, each with separate correlation information.
When a target UE's PDU session involves multiple Data Network (DN) connections (i.e. multiple connections to the same DN as described in clause A.3 of the present document), the generation and delivery of xCC shall be done in such a way that:
  • All applicable user plane packets are captured and delivered.
  • Duplicate delivery of CC is suppressed to the extent possible.
  • Each user plane packet is delivered with the associated DN Access Identifier (DNAI).
A PDU session may involve more than one UPFs. In that case, the CC-TF present in the SMF shall determine which UPF(s) is (are) more suitable to provide the CC-POI functions adhering to the above requirements. Furthermore, independent of which UPF is used to generate the xCC, the CC delivered from the MDF3 shall be correlated to the IRI messages related to the PDU session.
Up

6.2.3.7  Multi-Access PDU (MA PDU) Session Specificp. 51

The IRI-POI present in the SMF shall generate xIRI, for MA PDU sessions when it detects events or information as in clause 6.2.3.3, with the following clarifications.
The PDU session establishment xIRI:
  • When a UE request for an MA PDU session is received at the SMF (for one or more access types).
  • When a UE request for a single access PDU session is received at the SMF with an upgrade indicator to an MA PDU and the SMF chooses to establish an MA PDU session.
The PDU session modification xIRI:
  • When an MA PDU Session is modified by releasing or adding an access type.
  • When a UE request for a mid-session upgrade to MA PDU session is received at the SMF.
The PDU session release xIRI:
  • When the entire PDU session is released.
Each user plane packet of the MA PDU session should be able to be associated to the access type.
Up

6.2.3.8  LI state transfers in SMF setsp. 52

Copy of original 3GPP image for 3GPP TS 33.127, Fig. 6.2-4A: LI architecture diagram for SMF/UPF interception when using SMF sets and LISSF
Up
If an SMF belongs to an SMF set, then the TF present in the SMF shall have the ability to modify or stop the interceptions in the POIs present in the UPF irrespective of which TF present in an SMF from that SMF set had previously initiated the interception. A TF in one SMF of an SMF set may initiate the interception at a POI present in the UPF, the TF present in another SMF of the SMF set may make changes to the interception in that POI, and a TF in a different SMF of the SMF set may stop the interception in that POI.
In order to allow the TFs present in different SMFs of an SMF set to manage the interceptions at the POI present in an UPF, a new LI function referred to as LI State Storage Function (LISSF) is introduced. The TF that initiates the interception at a POI present in the UPF stores the related necessary information (e.g. correlation information) in case a different TF has to manage the interception at that POI. This necessary related information is referred to as LI state information (see TS 33.128 for the details).
If an SMF belongs to an SMF set, then the POI present in the SMF shall have the ability to continue the interception using the same correlation information or stop the interception even when the SMF that manages the PDU session changes.
In order to allow the POIs present in different SMFs of an SMF set to continue the interception by maintaining a continuity, the LISSF mentioned above is used by storing the LI state information. When required, the POI present in the SMF of an SMF set stores the LI state information in the LISSF. The POI present in another SMF of the same SMF can retrieve the LI state information from that LISSF to provide a continued interception.
When an SMF in an SMF set requests SM context information related to a target from a UDSF or receives SM context information from another SMF, the TF and POI within the SMF shall retrieve also the relevant LI state information from the shared LISSF.
If the implementation of the SMF set does not ensure that active SM contexts are always present in some SMF of the SMF set, the TF shall also retrieve the relevant LI state information when an existing task is deactivated by the LIPF.
Up

6.2.3.9  Interface LI_STp. 53

LI_ST is an interface between the LISSF and the LIPF and between the LISSF and other LI functions. It is used for transferring LI state information. The LI functions may request, store or erase LI state information from the LISSF using this interface. LI functions need to be authorized by the LIPF to have access to a specific instance of the LISSF before using the LI_ST interface.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 6.2-4B: Use of the LI_ST interface in the LI architecture.
Up

6.2.4  LI at UDM for 5Gp. 53

In 5G packet core network, the UDM provides the unified data management for UE. The UDM shall have LI capabilities to generate the target UE's service area registration related xIRI. See clause 7.2.2 for the details.

Up   Top   ToC