Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.128  Word version:  18.6.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.7…   6…   6.2.2.2A…   6.2.3…   6.2.3.2.7…   6.2.3.3…   6.2.4…   6.3…   6.3.2.2A…   6.3.3…   6.3.3.2…   6.3.3.2.4…   6.3.3.2A…   7…   7.3…   7.3.3…   7.3.3.2.21…   7.3.3.2.42…   7.3.3.2.63…   7.3.4…   7.4…   7.4.3.8…   7.5…   7.6…   7.7…   7.7.4…   7.8…   7.8.4…   7.9…   7.10…   7.10.4…   7.11…   7.12…   7.13…   7.13.3…   7.13.3.4…   7.14…   7.15…   8…   A…   D…   E…   M… 
6.2.2.2A Definitions for AMF message Types  6.2.2.2A.1 Type: InitialRANUEContextSetup  6.2.2.2A.2 Type: PDUSessionSetupRequestItem  6.2.2.2A.3 Type: UERadioCapability  6.2.2.2A.4 Type: UERadioCapabilityForPaging  6.2.2.2A.5 Type: NRV2XServicesAuthorization  6.2.2.2A.6 Type: LTEV2XServicesAuthorization  6.2.2.2A.7 Type: TargetNSSAIInfo  6.2.2.2A.8 Type: FiveGProSeAuthorizationIndication  6.2.2.2A.9 Enumeration: IABAuthorizedIndicator  6.2.2.2A.10 Enumeration: V2XUEAuthorizationIndicator  6.2.2.2A.11 Enumeration: FiveGProSeAuthorizationIndicator  6.2.2.3 Generation of IRI over LI_HI2  6.2.2.4 Identity privacy  6.2.2A Identifier Reporting for AMF  6.2.2A.1 Activation of reporting over LI_XEM1  6.2.2A.2 Generation of records over LI_XER 
...

 

6.2.2.2A  Definitions for AMF message Types  p. 64

6.2.2.2A.1  Type: InitialRANUEContextSetup  p. 64
The purpose of the InitialRANUEContextSetup type is to provide information the AMF sends to the NG-RAN to request the setup of the UE context. Encoded per clause 9.2.2.1 of TS 38.413.
Table 6.2.2.2A.1-1 contains the details for the InitialRANUEContextSetup type.
Field name Type Cardi­nality Description M/C/O
aMFUENGAPIDAMFUENGAPID1Identity that the AMF uses to uniquely identify the target UE over the NG Interface, See clause 9.3.3.1 of TS 38.413.M
rANUENGAPIDRANUENGAPID1Identity that the AMF receives from the NG-RAN node uniquely identifying the target UE within the NG-RAN Node. See clause 9.3.3.2 of TS 38.413.M
oldAMFGUAMI0..1Previous serving AMF's GUAMI, include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Format is defined in clause 5.3.4.1 of TS 29.571.C
pDUSessionSetupRequestSEQUENCE (SIZE (1..MAX)) OF PDUSessionSetupRequestItem1..MAXIdentifies the PDU Sessions for a UE. Derived from the information in the PDU Session Resource Setup Request Item IE defined in clause 9.2.2.1 of TS 38.413.M
allowedNSSAIAllowedNSSAI1Indicates the S-NSSAIs permitted by the network.M
mobilityRestrictionListMobilityRestrictionList0..1Provides roaming or access restrictions related to mobility from AMF to the RAN Node. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. See clause 9.3.1.85 of TS 38.413.C
uERadioCapabilityUERadioCapability0..1 Contains the UE Radio Capability information. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Defined in clauses 9.3.1.74 and 9.3.1.74a of TS 38.413.C
rATFrequencySelectionPriorityRATFrequencySelectionPriority0..1Used to define local configuration for RRM strategies. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. See clause 9.3.1.61 of TS 38.413.C
uERadioCapabilityForPagingUERadioCapabilityForPaging0..1Contains paging specific UE Radio Capability information. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Defined in clause 9.3.1.68 of TS 38.413.C
iABAuthorizedIndicatorIABAuthorizedIndicator0..1Provides information about the authorization status of the UE to operate as an IAB node. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. See clause 9.3.1.129 of TS 38.413.C
nRV2XServicesAuthorizationNRV2XServicesAuthorization0..1Provides information on the authorization status of the UE to use the NR sidelink for V2X services. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. See clause 9.3.1.146 of TS 38.413.C
lTEV2XServiceAuthorizationLTEV2XServiceAuthorization0..1Provides information on the authorization status of the UE to use the LTE sidelink for V2X services. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. See clause 9.3.1.147 of TS 38.413.C
rGLevelWirelineAccessCharacteristicsOCTET STRING0..1Indicates the wireline access technology specific QoS information corresponding to a specific wireline access subscription. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Specified in clause 4.5.1.2 of TS 23.316.C
uERadioCapabilityIDOCTET STRING0..1Identifier used to represent a set of UE radio capabilities. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Defined in clause 29.2 of TS 23.003.C
targetNSSAIInfoTargetNSSAIInfo0..1Contains the Target NSSAI and Index to RAT/Frequency Selection Priority. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Defined in clause 9.3.1.229 of TS 38.413.C
fiveGProSeAuthorizationIndicationFiveGProSeAuthorizationIndication0..1Provides information on the authorization status of the UE to use ProSe services. Include when sent in the INITIAL CONTEXT SETUP REQUEST or when known at the NF. Defined in clause 9.3.1.233 of TS 38.413.C
Up
6.2.2.2A.2  Type: PDUSessionSetupRequestItem  p. 65
The PDUSessionSetupRequestItem identifies a PDU Session for a UE. The PDUSessionSetupRequestItem is derived from the information in the PDU Session Resource Setup Request Item IE defined in clause 9.2.2.1 of TS 38.413.
Table 6.2.2.2A.2-1 contains the details for the PDUSessionSetupRequestItem type.
Field name Type Cardi­nality Description M/C/O
pDUSessionIDPDUSessionID1Identifies a PDU Session for a UE. The definition and use of the PDU Session ID is specified in clause 5.6 of TS 23.501.M
sNSSAISNSSAI1Slice identifier associated with the PDU session, if available. See clause 28.4.2 of TS 23.003 and clause 5.15.2 of TS 23.501.M
Up
6.2.2.2A.3  Type: UERadioCapability  p. 66
The UERadioCapability contains the UE radio access capability information. The UERadioCapability type is derived from UE Radio Capability IE defined in clauses 9.3.1.74 and 9.3.1.74a of TS 38.413.
Table 6.2.2.2A.3-1 contains the details for the UERadioCapability type.
Field name Type Cardi­nality Description M/C/O
uERadioCapibilityNROCTET STRING0..1Includes the UE Radio Capability information as defined in clause 9.3.1.74 of TS 38.413.C
uERadioCapabilityEUTRAOCTET STRING0..1Includes the UE Radio Capability - E-UTRA Format information message defined in clause 9.3.1.74a of TS 38.413.C
Up
6.2.2.2A.4  Type: UERadioCapabilityForPaging  p. 66
The UERadioCapabilityForPaging contains paging specific UE Radio Capability information. The UERadioCapabilityForPaging type is derived from the UE Radio Capability for Paging IE defined in clause 9.3.1.68 of TS 38.413.
Table 6.2.2.2A.4-1 contains the details for the UERadioCapabilityForPaging type.
Field name Type Cardi­nality Description M/C/O
uERadioCapabilityForPagingOfNROCTET STRING0..1Includes the UE Radio Capability Paging of NR information as defined in clause 9.3.1.68 of TS 38.413.C
uERadioCapabilityForPagingOfEUTRAOCTET STRING0..1Includes the UE Radio Capability Paging of E-UTRA information as defined in clause 9.3.1.68 of TS 38.413.C
uERadioCapabilityForPagingOfNBIoTOCTET STRING0..1Includes the UE Radio Capability Paging of NB-IoT information as defined in clause 9.3.1.68 of TS 38.413.C
Up
6.2.2.2A.5  Type: NRV2XServicesAuthorization  p. 66
The NRV2XServicesAuthorization provides information on the authorization status of the UE to use the NR sidelink for V2X services. Defined in clause 9.3.1.146 of TS 38.413.
Table 6.2.2.2A.5-1 contains the details for the NRV2XServicesAuthorization type.
Field name Type Cardi­nality Description M/C/O
v2XVehicleUEAuthorizationIndicatorV2XUEAuthorizationIndicator0..1Indicates whether the UE is authorized as Vehicle UE.C
v2XPedestrianUEAuthorizationIndicatorV2XUEAuthorizationIndicator0..1Indicates whether the UE is authorized as Pedestrian UE.C
Up
6.2.2.2A.6  Type: LTEV2XServicesAuthorization  p. 67
The LTEV2XServicesAuthorization provides information on the authorization status of the UE to use the LTE sidelink for V2X services. Defined in clause 9.3.1.147 of TS 38.413.
Table 6.2.2.2A.6-1 contains the details for the NRV2XServicesAuthorization type.
Field name Type Cardi­nality Description M/C/O
v2XVehicleUEAuthorizationIndicatorV2XUEAuthorizationIndicator0..1Indicates whether the UE is authorized as Vehicle UE.C
v2XPedestrianUEAuthorizationIndicatorV2XUEAuthorizationIndicator0..1Indicates whether the UE is authorized as Pedestrian UE.C
Up
6.2.2.2A.7  Type: TargetNSSAIInfo  p. 67
The TargetNSSAIInfo contains the Target NSSAI and Index to RAT/Frequency Selection Priority. Derived from Target NSSAI Information IE defined in clause 9.3.1.229 of TS 38.413.
Table 6.2.2.2A.7-1 contains the details for the TargetNSSAIInfo type.
Field name Type Cardi­nality Description M/C/O
targetSNSSAIListNSSAI0..1Contains the Target S-NSSAI list. Derived from the Target NSSAI IE specified in clause 9.3.1.230 of TS 38.413.M
rATFrequencySelectionPriorityRATFrequencySelectionPriority0..1Used to define local configuration for RRM strategies.M
Up
6.2.2.2A.8  Type: FiveGProSeAuthorizationIndication  p. 67
The FiveGProSeAuthorizationIndication provides information on the authorization status of the UE to use the 5G ProSe services. Derived from 5G ProSe Authorized IE defined in clause 9.3.1.233 of TS 38.413.
Table 6.2.2.2A.8-1 contains the details for the FiveGProSeAuthorizationIndication type.
Field name Type Cardi­nality Description M/C/O
fiveGProSeDirectDiscoveryFiveGProSeAuthorizationIndicator0..1Indicates whether the UE is authorized for 5G ProSe Direct Discovery.C
fiveGProSeDirectCommunicationFiveGProSeAuthorizationIndicator0..1Indicates whether the UE is authorized for 5G ProSe Direct Communication.C
fiveGProSeL2UEToNetworkRelayFiveGProSeAuthorizationIndicator0..1Indicates whether the UE is authorized for 5G ProSe Layer-2 UE-to-Network Relay.C
fiveGProSeL3UEToNetworkRelayFiveGProSeAuthorizationIndicator0..1Indicates whether the UE is authorized for 5G ProSe Layer-3 UE-to-Network Relay.C
fiveGProSeL2RemoteUEFiveGProSeAuthorizationIndicator0..1Indicates whether the UE is authorized for 5G ProSe Layer-2 Remote UE.C
Up
6.2.2.2A.9  Enumeration: IABAuthorizedIndicator  p. 68
The IABAuthorizedIndicator provides information about the authorization status of the IAB node. Defined in clause 9.3.1.129 of TS 38.413.
Table 6.2.2.2A.9-1 contains the details of the IABAuthorizedIndicator type.
Enumeration value Description
authorized(1)Indicates the UE is authorized to operate as an IAB node.
notAuthorized(2)Indicates the UE is not authorized to operate as an IAB node.
Up
6.2.2.2A.10  Enumeration: V2XUEAuthorizationIndicator  p. 68
The V2XUEAuthorizationIndicator indicates whether the UE is authorized to use Sidelink for V2X operation. Derived from the IEs defined in clauses 9.3.1.146 and 9.3.1.147 of TS 38.413.
Table 6.2.2.2A.10-1 contains the details of the V2XUEAuthorizationIndicator type.
Enumeration value Description
authorized(1)Sidelink for V2X operation is authorized.
notAuthorized(2)Sidelink for V2X operation is not authorized.
Up
6.2.2.2A.11  Enumeration: FiveGProSeAuthorizationIndicator  p. 68
The FiveGProSeAuthorizationIndicator indicates authorization status of the UE to use the 5G ProSe services. Derived from the 5G ProSe Authorized IE defined in clause 9.3.1.233 of TS 38.413.
Table 6.2.2.2A.11-1 contains the details of the FiveGProSeAuthorizationIndicator type.
Enumeration value Description
authorized(1)5G ProSe service is authorized.
notAuthorized(2)5G ProSe service is not authorized.
Up

6.2.2.3  Generation of IRI over LI_HI2  p. 68

When an xIRI is received over LI_X2 from the IRI-POI in AMF, the MDF2 shall generate the corresponding IRI message and deliver over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received in the xIRI over LI_X2. This record may be enriched with any additional information available at the MDF (e.g. additional location information).
The timestamp field of the PSHeader structure shall be set to the time at which the AMF event was observed (i.e. the timestamp field of the X2 PDU).
The IRI type parameter (see ETSI TS 102 232-1 [9] clause 5.2.10) shall be included and coded according to Table 6.2.2-7.
IRI message IRI type
AMFRegistrationREPORT
AMFDeregistrationREPORT
AMFLocationUpdateREPORT
AMFStartOfInterceptionWithRegisteredUEREPORT
AMFUnsuccessfulProcedureREPORT
AMFIdentifierAssociationREPORT
AMFPositioningInfoTransferREPORT
AMFRANHandoverCommandREPORT
AMFRANHandoverRequestREPORT
AMFUEConfigurationUpdateREPORT
AMFRANTraceReportREPORT
AMFUEPolicyTransferREPORT
AMFUEServiceAcceptREPORT
These IRI messages shall omit the CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).
The threeGPP33128DefinedIRI field in ETSI TS 102 232-7 [10] clause 15 shall be populated with the BER-encoded IRIPayload.
When an additional warrant is activated on a target UE and the LIPF uses the same XID for the additional warrant, the MDF2 shall be able to generate and deliver the IRI message containing the AMFStartOfInterceptionWithRegisteredUE record to the LEMF associated with the additional warrant without receiving a corresponding xIRI. The payload of the AMFStartOfInterceptionWithRegisteredUE record is specified in Table 6.2.2.2.5-1.
If the MDF2 did not receive from the IRI-POI the value of timeOfRegistration parameter in a previous corresponding AMFStartOfInterceptionWithRegisteredUE for the same registration, the MDF2 shall include in that parameter the time provided in the timestamp previously received in the header of the related AMFRegistration xIRI.
Up

6.2.2.4  Identity privacy  p. 69

The AMF shall ensure for every registration (including re-registration) that SUPI has been provided by the UDM to the AMF and that the SUCI to SUPI mapping has been verified as defined in TS 33.501. This shall be performed regardless of whether the SUPI is a target of interception, and whether the null encryption algorithm is used for the SUCI. The AMF shall maintain the SUPI to SUCI mapping for at least the lifetime of the registration in order to allow interception based on SUPI after the initial registration.
Up

6.2.2A  Identifier Reporting for AMF  p. 69

6.2.2A.1  Activation of reporting over LI_XEM1  p. 69

The IEF in the AMF is activated and deactivated over LI_XEM1 by the LIPF using the LI_XEM1 protocol described in clause 5.2.7.
Upon receiving a valid activate task message over LI_XEM1, the IEF shall start generating records as defined in clause 6.2.2A.2.
Upon receiving a valid deactivate task message over LI_XEM1, the IEF shall stop generating records as defined in clause 6.2.2A.2.
Up

6.2.2A.2  Generation of records over LI_XER  p. 70

6.2.2A.2.1  Events  p. 70
The IEF in the AMF shall generate an IEFIdentifierAssociation record whenever the IEF present in the AMF detects a change in association between a SUPI and a 5G-GUTI for any UE registered with the AMF. The IEF shall send the IEFIdentifierAssociation records to the ICF over LI_XER as defined in clause 5.9.
Accordingly, the IEF in the AMF generates IEFIdentifierAssociation records when any of the following events are detected:
  • IEFAssociationRecord: Association of a 5G-GUTI to a SUPI, (this may also include SUCI to SUPI association).
  • IEFDeassociationRecord: De-association of a 5G-GUTI from a SUPI.
In addition, when an IEF is activated as per clause 6.2.2A.1, the IEF shall generate associations event for all SUPIs which are registered in the AMF, where those identifier associations allocated prior to IEF activation remain current and are still available in the AMF (See NOTE 2).
In the case where the IEF in the AMF detects that a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE (5G-GUTI) message as defined in TS 24.501 has been sent by the AMF towards a UE, the IEF shall immediately generate an IEFIdentifierAssociation record. This record shall be generated regardless of whether the CONFIGURATION UPDATE (5G-GUTI) or REGISTRATION ACCEPT procedure is subsequently successfully completed or not.
Up
6.2.2A.2.2  Association Events  p. 70
For each association event, the IEF shall create an IEFAssociationRecord, as defined below.
Field Name Description M/C/O
sUPISUPI associated with detected association event.M
fiveGGUTI 5G-GUTI shall be provided. Encoded as per TS 24.501 Figure 9.11.3.4.1, omitting the first four octets.M
timeStampTime at which the identifier association event occurred. Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time).M
tAILast known TAI associated with the SUPI. Encoded as per clause 9.11.3.8 of TS 24.501, omitting the first octet.M
nCGILast known nCGI(s) available when identifier association event detected. Given as a sequence of PLMNID (encoded as per clause 9.3.3.5 of TS 38.413) and NCI (encoded as per clause 9.3.1.7 of TS 38.413). M
nCGITimeueLocationTimestamp(s) of nCGIs if available in AMF as per clause 5.4.4.9 of TS 29.571. If ueLocationTimestamp(s) is not available, shall be populated with timeStamp(s) of when last known nCGI(s), were obtained and stored by the AMF.M
sUCISUCI shall be provided when event is triggered by association of a SUCI to a SUPI. Encoded as per clause 9.11.3.4 of TS 24.501, omitting the first 3 octets.C
pEIPEI, (see NOTE 1).C
fiveGSTAIListList of tracking areas associated with the registration area within which the UE is current registered, see clause 9.11.3.9 of TS 24.501. (see NOTE 2)C
gPSIGPSI, (see NOTE 1).C
NOTE 1:
Shall be provided in first association record to ICF after PEI or GPSI is available and following any change of PEI or GPSI.
NOTE 2:
As a minimum, list of tracking areas shall be included in the first association event for each SUPI registered (per UE session) with the AMF and additionally whenever the TAI list changes due to a change in registration area.
For each de-association event, the IEF shall create an IEFDeassociationRecord, as defined below.
Field Name Description M/C/O
sUPISUPI associated with detected de-association event.M
fiveGGUTI 5G-GUTI shall be provided. Encoded as per TS 24.501 Figure 9.11.3.4.1, omitting the first four octets.M
timeStampTime at which the identifier de-association event occurred. Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time).M
nCGILast known nCGI(s) available when identifier de-association event detected. Given as a sequence of PLMNID (encoded as per clause 9.3.3.5 of TS 38.413) and NCI (encoded as per clause 9.3.1.7 of TS 38.413).M
nCGITimeueLocationTimestamp(s) of nCGIs if available in AMF as per clause 5.4.4.9 of TS 29.571. If ueLocationTimestamp(s) is not available, shall be populated with timeStamp(s) of when last known nCGI(s), were obtained and stored by the AMF.M
Up
6.2.2A.2.3  Transmission to the ICF  p. 71
When activated (see clause 5.2.7), the IEF shall establish a TLS connection to the ICF as given over LI_XEM1. If the IEF fails to establish a TLS connection, it shall report an error over LI_XEM1 using the error reporting mechanisms described in ETSI TS 103 221-1 [7] and attempt to reconnect after a configurable period of time.
When a record has been generated as described in clause 6.2.2A.2.2, the IEF shall encode the IEFAssociationRecord or IEFDeassociationRecord as a BER-encoded IEFMessage structure, following the ASN.1 schema given in Annex F, and transmit it to the ICF over the established TLS connection.
The IEF may transmit a keepalive request using the keepalive record defined in Annex F. Upon receiving a keepalive request, the ICF shall respond with a keepaliveResponse record containing the same sequence number used in the request. The circumstances under which the IEF transmits keepalive requests is out of scope of the present document.
Up

Up   Top   ToC