Multi-Operator Demo Test Discussion

[gmuratk]

This is a discussion for high level test plan for the multi operator demonstration mentioned in #81

Version: https://github.com/camaraproject/DeviceStatus/tree/6f686d3d3f32d978af0e4bc6c4fe2d94dd23ddd6
Scope: Roaming Status Query (POST /roaming)

TEST PLAN
/roaming

1. Test One
   • Pre-condition: Drone connected to network (no flying required). Connectivity is maintained throughout testing.
   • Steps:
     • POST /roaming API
       • Input: PhoneNumber
   • Expected Result: Valid response with roaming as false,
2. Test Two
   • Pre-condition: Drone NOT connected to network
   • Steps:
     • POST /roaming API
       • Input: PhoneNumber
   • Expected Result: Valid response with roaming as false

[ChrisC-att]

Can you explain the rationale for test two ?
it feels strange to respond with roaming status false if the device is not connected, there is no guarantee that this is the case
we would have expected that if the device is not connected you get something like :
{
"status": 503,
"code": "UNAVAILABLE",
"message": "Device not in network"
}

[gmuratk]

Intent was to provide a high-level plan and not detailed request / response per agreement with the involved operators. A valid response to each test must comply with the schema for the version selected for the effort.

[lbertz02]

Would 503 be correct code? It is implying the Server is not ready because the device is not on the network. Would being connected via signaling but no PDU session also be something that is accounted for in the long run and is 503 appropriate there?

[maheshc01]

sharing my opinion that 503 HTTP response code would not be appropriate to use when device is not connected. 503 is communicating on the server readiness where as device not being connected is a valid response from the server perspective.

Alternatively, using HTTP 404 also would not be appropriate in this scenario as the device was found but it was not connected at the moment. 404 should be used when the device was not found by the operator indicating developers might be trying to use a device data who is not a subscriber for the particular network operator.

Can we consider adding an additional field indicating connectivity status. this would be borrowing the capability from /connectivity API but we can keep it simple as just connectivity Status as yes or no without getting into specifics of SMS vs DATA.
If we introduce the new field, the API response code would be 200 with response body indicating Device not connected information.

we could also take it further and combine /roaming and /connectivity into 1 API. If input for both the APIs is exactly the same then why not provide both roaming and connectivity status in the same API and let the developers pick what they need from the response body. This would avoid developers from coding against 2 different API with unique endpoints.

[gmuratk]

note: the country code & name removed from the successful response to test one, as for this effort mandatory fields will suffice.

[gmuratk]

Testing based on the above high-level test plan has been completed.

• Test completed: 12/14/2023
• Network: T-Mobile production
• Device: Drone using ModalAI VOXL2 compute solution with certified Quectel 502Q-AE
• API Client software: curl, python (multiple)
• Test Results: Passed (All)
• Exceptions: None