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.