Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.127  Word version:  18.8.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.5  LI at SMSFp. 54

6.2.5.1  Architecturep. 54

In the 5GC network, the SMSF provides functionalities to support the SMS over NAS. The SMSF shall have LI capabilities to generate xIRIs when SMS related to the target UE are handled. Extending the generic LI architecture presented in clause 5, Figure 6.2-5 below gives a reference point representation of the LI architecture with SMSF as a CP NF providing the IRI-POI functions.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 6.2-5: LI architecture for LI at SMSF
Figure 6.2-5: LI architecture for LI at SMSF
(⇒ 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 the same to the LIPF.
The LIPF present in the ADMF provisions the IRI-POI present in the SMSF and the MDF2 over LI_X1 interfaces. The LIPF may interact with the SIRF (over LI_SI) present in the NRF to discover the SMSFs in the network.
The IRI-POI present in the SMSF detects the target UE's SMS, generates and delivers the xIRI to the MDF2 over LI_X2. The xIRI will contain the SMS payload. The MDF2 shall support the capability to deliver the IRI messages including the SMS payload as part of the Interception Product to the LEMF over LI_HI2.
National regulations may require that the MDF2 remove information regarded as content from the payload in case of an IRI only warrant.
Up

6.2.5.2  Target identitiesp. 55

The LIPF present in the ADMF provisions the intercept information associated with the following target identities to the IRI-POI present in the SMSF:
  • 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.5.3  IRI eventsp. 56

The IRI-POI present in the SMSF shall generate xIRI, when it detects the following specific events or information:
  • SMS message.
The SMS message xIRI is generated when the IRI-POI present in an SMSF detects that an SMS message for the target UE is handled.

6.2.5.4  Common IRI parametersp. 56

The list of xIRI parameters is specified in TS 33.128. The xIRIs shall include at the minimum the following information:
  • Target identity.
  • Time stamp.
  • Location information.
  • SMS message direction (mobile originated, mobile terminated).
  • SMS message payload.

6.2.5.5  Specific IRI parametersp. 56

The parameters in each xIRI are defined in TS 33.128.

6.2.5.6  Network topologiesp. 56

The SMSF shall provide the IRI-POI functions in the following network topology cases:
  • Non-roaming case.
  • Roaming case, in VPLMN.

6.2.6  LI support at NRFp. 56

6.2.6.1  Architecturep. 56

In 5G, network functions that support SBA register with the NRF after instantiation. The NRF thus provides the network repository functions and is aware of all the NFs that have been instantiated. The present document refers to this as system information.
The SIRF present in the NRF provides the system information to LIPF present in the ADMF, in order for the LIPF to establish which NFs (and therefore POIs) are applicable to a specific target user's services. LI function service discovery is described in clause 5.5.
An architecture diagram depicting this LI at NRF is shown in Figure 6.2-6 below.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 6.2-6: LI Architecture depicting NRF as an SIRF
Up
Figure 6.2-6 shows the architecture illustrating the SIRF functions within the NRF.
The LIPF present in the ADMF interacts with the SIRF (over LI_SI) present in the NRF to obtain the system information.

6.2.6.2  LI_SI notificationsp. 57

The SIRF present in the NRF shall generate notifications over LI_SI when the SIRF detects the following specific events or information:
  • NF service registration.
  • NF service update.
  • NF service deregistration.
  • NF service chain change.
The NF service chain change notification shall be generated whenever an NF is added to or removed from a service chain in response to NF discovery and selection events.

6.2.6.3  LI_SI parametersp. 57

The notifications reported over LI_SI by the SIRF shall include the following information elements:

6.2.7  External data storagep. 58

6.2.7.1  UDSF or UDRp. 58

The UDSF or UDR as defined in TS 23.501 are used to externally store data relating to one or more NFs, separating the compute and storage elements of an NF. Where the NF contains a POI the following restrictions on the use of the UDSF/UDR shall apply:
  • The UDSF/UDR shall be subject to the same location, geographic, security and other physical environment constraints as the NF POI for which it is storing data.
  • No LI specific POI data (e.g. target list) shall be stored in the UDSF/UDR unless storage is directly under the control of the POI within the NF.
  • LI data stored in a UDSF/UDR shall only be accessible by the specific individual POI for which the UDSF/UDR is storing data and that data shall not be shared between POIs unless specifically authorised by the LICF within the ADMF.
  • By default, LI data shall not be stored in a UDSF/UDR which is shared by multiple NFs unless specifically authorised by the LICF.
  • Any storage of LI data outside of the POI in the UDSF/UDR shall be auditable by the LICF.
  • The interface between the POI/NF and the UDSF/UDR shall be protected such that an attacker cannot identify targeted users based on observation of this interface. (i.e. access to the UDSF/UDR shall be identical for both intercepted and non-intercepted user communications).
  • The use and placement of a UDSF/UDR within an NF/POI design shall not introduce additional interception delay compared with non-separated compute and storage.
  • Where the POI requires access to NF data that is stored in the UDSF/UDR, non-LI network functions and processes or non-LI authorised personnel shall not be able to detect POI access to that data in the UDSF/UDR.
  • The POI and LICF/MDF shall be responsible for managing encryption of LI data stored in the UDSF/UDR for the POI in addition to any default encryption applied by the NF.
The above requirements shall apply when the UDSF/UDR provide data storage for TF/NF.
Up

6.2.7.2  LI State Storage Function (LISSF)p. 58

The LISSF is a function that makes it possible for other LI functions to share information with each other. There can be multiple instances of the LISSF in the network being handled by the same ADMF. The LISSF can be implemented as a separate function or within the ADMF. The LISSF may be used to transfer LI state information between LI functions. The following restrictions on the use of the LISSF shall apply:
  • The LISSF shall be subject to the same location, geographic, security and other physical environment constraints as the LI functions for which it is storing data.
  • LI state information stored in an LISSF shall only be accessible by the LI functions specifically authorised by the LICF.
  • Other than the time required to acquire the LI state information, the use and placement of an LISSF within the LI architecture shall not introduce additional delay.
  • The LISSF shall be directly under the control of the ADMF, and it shall be directly accessible and auditable by the LICF.
Up

Up   Top   ToC