Attention is currently required from: laforge.

View Change

1 comment:

• Commit Message:

  • Patch Set #2, 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 change 37393. To unsubscribe, or for help writing mail filters, visit settings.