Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transaction ID (supported)
LMF Measurement ID (supported)
RAN Measurement ID (supported)
Add F1AP positioning measurement failure indication message enc/dec + test
Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transaction ID (supported)
LMF Measurement ID (supported)
RAN Measurement ID (supported)
Cause (supported)
Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transaction ID (supported)
LMF Measurement ID (supported)
RAN Measurement ID (supported)
Positioning Measurement Result List (range: 1)
> Positioning Measurement Result List Item (range: 1..64)
>> Positioning Measurement Result (supported)
>> TRP ID (supported)
Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transaction ID (supported)
LMF Measurement ID (supported)
RAN Measurement ID (supported)
Cause (supported)
Optional fields:
Criticality Diagnostics (not supported)
Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transcation ID (supported)
LMF Measurement ID (supported)
RAN Measurement ID (supported)
Positioning Measurement Result List (range: 0..1)
> Positioning Measurement Result List Item (range: 1..64)
>> Positioning Measurement Result (supported)
>> TRP ID (supported)
Optional fields:
Criticality Diagnostics (not supported)
Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transcation ID (supported)
TRP Information List (range : 1)
> TRP Information Item (range : 1..65535)
>> TRP Information (supported)
Further details of TRP Information:
TRP ID
TRP Information Type Response List (range : 1)
> TRP Information Type Response Item (range : 1..64)
>> CHOICE TRP Information Type Response Item
>>> NR PCI (madatory : supported)
>>> NG-RAN CGI (madatory : supported)
>>> NR ARFCN (madatory : supported)
>>> PRS Configuration (madatory : not supported)
>>> SSB Information (madatory : not supported)
>>> SFN Initialisation Time (madatory : not supported)
>>> Spatial Direction Information (madatory : not supported)
>>> Geographical Coordinates (madatory : supported)
For now, we only use Geographical Coordinates.
Optional fields:
Criticality Diagnostics (not supported)
Reference: 3GPP 38.473 v16.21.0
Mandatory fields:
Transcation ID (supported)
TRP list (range : 0..1)
> TRP list Item (range : 1..65535)
>> TRP ID (supported)
TRP Information Type List (range : 1)
> TRP Information Type Item (range : 1..64)
>> TRP Information Type Item (supported)
While implementing NRPPA-related F1AP messages, we remarked that
extension field "UL-AoA-ExtIEs" needs to be OPTIONAL (e.g., in NRPPA it
is optional in the OAI-compiled version), but it was not marked as such.
This later version 16.21.0 fixes this.
Similarly to the commit "Use F1 UE context setup/modif Request in
stack", we do both UE context setup/modification response at once
because of some functions that are shared by the MAC message handler.
Use the new, tested F1 UE context setup request and modification
requests in the stack.
We have to do both at once, because there are some functions that are
used by handlers for both messages, notably
- handle_ue_context_drbs_setup()
- handle_ue_context_srbs_setup()
(+ and some functions called by those two). For instance, the first uses
the (new/old) type f1ap_drb_to_be_setup_t/f1ap_drb_to_setup_t which is
shared. The alternative would be to duplicate the functionality
temporarily, and I want to avoid unnecessary code churn.
Reintroduce separate message types to simplify the encoding/decoding,
including shorter names. The old types will be removed once everything
has been migrated to the new encoder/decoder, which should ensure that
everything is properly migrated to the unit-tested encoder/decoders.
Also, for each type of F1 message (F1 UE context setup request,
response, modification request, ...) introduce a separate type to avoid
to mistakenly use wrong fields, which can lead to bugs. In this regard,
the DL PDCP SN bit size in the DRB-ToBeSetup list of the UE context
setup request is optional, as it will also be used in the UE context
modification request DRB SetupMod list (which avoids quite some code
duplication). The encoder checks that this IE is present, though.
F1AP_LIB_FIND_IE() is used to look up elements in a list, but was
hitherto hardcoded to use "protocolIEs" as an intermediate struct. A
follow-up commit will use this macro where we don't have protocolIEs,
but "iE_Extensions". Hence, modify to make it work for that case (and
others) as well.
Introduce generic _F1_CHECK_EXP(), which is like the macros for checking
values (_F1_EQ_CHECK_INT() etc). Reuse the same for introducing
_F1_EQ_CHECK_OPTIONAL_IE that will be used to write the check for
optional fields more concisely.
CP_OPT_BYTE_ARRAY() FREE_OPT_BYTE_ARRAY() are macros to wrap handling of
optional byte arrays.
_F1_MALLOC() simplifies allocations and is similar to asn1cCallocOne(),
but provided to avoid confusion (since more than ASN.1 structures will
use it).
All will be used in the following commits.
Signal gNB-DU config update CellStatus from DU to CU
Add the cell status to gNB-DU configuration update message, including
test. Use the gNB-DU configuration update to signal the cell status in
the stack.
This IE was not included in a previous refactoring round, but is at
least necessary to be decoded when interoperating with the OSC O-DU.
This is preparatory work to allow NSA-like modes to be used over F1 in
the future. Notably, it fills the F1 message for UE context setup with
GTP TEID, and fills additional information to "make the F1 encoder
happy" (fill in QFI etc). Also, provide some F1 fixes to make this work.
Remove stale UE connections, if relevant.
Issue 947 and compilation improvements
This MR started with a small commit (03c7f151) to close#947. Little did
I know that I would be taken in a long journey through OAI compilation
hell.
- encode all SI containers the encoding function gets (it's not the
encoding function's job to enforce semantics)
-
Fixes: 30628b820c ("Add encoding/decoding lib for F1AP Setup Response
(Interface Management)")
Encapsulate the asn1c call from cmake in a cmake function run_asn1c().
As a notable change to the previous manual add_custom_command()
invocation, in suppresses the output of asn1c by default [1] and stores
it in a log file. In case of asn1c4 error, the output will output on
stdout.
Use the new run_asn1c() in all occasions for code generation.
[1] it is quite verbose, with many warnings that we cannot influence nor
suppress, and lists all generated files which is verified by the build
system automatically, anyway.
[E2 agent] RAN Control SM - support for REPORT Style 1 ("RRC Message" and "UE ID" RAN Parameter IDs)
[Spring of Code 2024] contributions
Extended the RAN Control Service Model at E2 Agent to support all RC
REPORT Styles (1 - 5)
Implemented the following RAN Parameter IDs for REPORT Style 1:
1. "RRC Message": any DL-DCCH, and any UL-DCCH
2. "UE ID": as per spec, when the RRC Setup Complete or F1 UE Context
Setup Request detected
As per spec, UE ID shall be reported when the message event configured by
the Event Trigger Style 1 is set to “RRC Setup Complete" message (UE attach), or
“Xn/NG Handover Request” or “F1 UE Context Setup Request” (Intra gNB Handover).
In OAI RAN, Xn/NG Handover is not yet supported, and therefore not added as the trigger event
in this commit.
Additionally, as the Event Trigger Definition Format 1 is common for both "RRC Message" and "UE ID",
E2 node will report the “RRC Setup Complete" message which the xApp will decode and print.
Co-authored-by: Khanh Toan Pham <khanh.toan.pham@hhi.fraunhofer.de>
Co-authored-by: Shrinish Donde <shrinish.donde@hhi.fraunhofer.de>
Co-authored-by: Theodoros Tsourdinis <theodoros.tsourdinis@sorbonne-universite.fr>
Co-authored-by: Miguel Fuentes <miguel.fuentes@i2cat.net>
Co-authored-by: Teodora Vladic <teodora.vladic@openairinterface.org>
Rakesh Mundlamuri