Attention is currently required from: laforge. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email ) Change subject: support RAB Assignment in cn_ranap_rx_*_msg_co() ...................................................................... Patch Set 2: (1 comment) Commit Message: https://gerrit.osmocom.org/c/osmo-iuh/+/37393/comment/49ee9033_44a78c0a PS2, Line 20: Procedure", but doesn't

I always assumed that the "outcome" is for the "intermediate" responses and the final response would […] My humble conclusion is to just accept all the variants that an implementation could sensibly choose. There are no adverse effects AFAICT.

Details: If an implementation were separating the outcomes by success/failure, each would have to be a separate RANAP PDU entirely: Below listings show how the [[un]successful]outcome is indicated once in the "top" of the RANAP PDU, and the RAB Assignment lists of actual detailed responses is deeper within that single PDU: ``` typedef struct RANAP_RANAP_PDU { RANAP_RANAP_PDU_PR present; union RANAP_RANAP_PDU_u { RANAP_InitiatingMessage_t initiatingMessage; RANAP_SuccessfulOutcome_t successfulOutcome; RANAP_UnsuccessfulOutcome_t unsuccessfulOutcome; RANAP_Outcome_t outcome; /* * This type is extensible, * possible extensions are below. */ } choice; /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } RANAP_RANAP_PDU_t; typedef struct RANAP_SuccessfulOutcome { RANAP_ProcedureCode_t procedureCode; --> "RAB Assignment" RANAP_Criticality_t criticality; ANY_t value; --> decoded to struct ranap_message /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } RANAP_SuccessfulOutcome_t; typedef struct ranap_message_s { uint8_t procedureCode; --> "RAB Assignment" uint8_t criticality; uint8_t direction; --> initiating/*outcome copied from RANAP_PDU union { ... RANAP_RAB_AssignmentRequestIEs_t raB_AssignmentRequestIEs; RANAP_RAB_AssignmentResponseIEs_t raB_AssignmentResponseIEs; ... } } typedef struct RANAP_RAB_AssignmentResponseIEs_s { uint16_t presenceMask; RANAP_RAB_SetupOrModifiedList_t raB_SetupOrModifiedList; ///< Optional field RANAP_RAB_ReleasedList_t raB_ReleasedList; ///< Optional field RANAP_RAB_QueuedList_t raB_QueuedList; ///< Optional field RANAP_RAB_FailedList_t raB_FailedList; ///< Optional field RANAP_RAB_ReleaseFailedList_t raB_ReleaseFailedList; ///< Optional field RANAP_CriticalityDiagnostics_t criticalityDiagnostics; ///< Optional field } RANAP_RAB_AssignmentResponseIEs_t; ``` A clear wording on which kind of outcome should be used doesn't seem to exist for Class 3, we only have this for Class 1: 3GPP TS 25.413 3.1: "[Class 1 EP...] Successful and Unsuccessful: - One signalling message reports both successful and unsuccessful outcome for the different included requests. The response message used is the one defined for successful outcome. " An implementation could assume the same for Class 3. Or they could return "outcome" for mixed outcomes. Or they could make it unsuccessful if >=1 items have failed... Each interpretation makes sense from different points of view. -- To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-iuh Gerrit-Branch: master Gerrit-Change-Id: Ifec566a98cb6141d27b9e5e33d5a78f8b1530658 Gerrit-Change-Number: 37393 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr@sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge@osmocom.org> Gerrit-Attention: laforge <laforge@osmocom.org> Gerrit-Comment-Date: Sat, 06 Jul 2024 14:55:07 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge@osmocom.org> Gerrit-MessageType: comment