Feature #4548: automatic test coverage for emergency call support on osmo-bsc - OsmoBSC - Open Source Mobile Communications

Custom queries

all-by-project

Actions

Copy link

Feature #4548

closed

automatic test coverage for emergency call support on osmo-bsc

Added by laforge almost 4 years ago. Updated over 3 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

dexter

Category:

Target version:

Start date:

05/12/2020

Due date:

% Done:

100%

Spec Reference:

Description

Emergency calls can be enabled/disabled on a per-BTS level. In OsmoMSC, you can configure the number to which emergency calls should be routed to.

They should be working, but I have the feeling it's one of those features that are rarely used in our existing user base, and we have zero automatic test coverage. Let's change that

Hide closed

Checklist

BSC_Tests.ttcn test handling CHAN RQD (BSC expeted to reject if "allow-emergency deny"; channel activation otherwise)
BSC_Tests.ttcn test handling EMERGENCY SETUP (BSC expected to reject if "allow-emergency deny", pass to A otherwise)
BTS_Tests.ttcn test sending RACH request for EMERGENCY

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by dexter almost 4 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by dexter almost 4 years ago

% Done changed from 0 to 10

I have the emergency call now running with a test setup so I can make traces.

Also I have added a testcase that sends a CHANNEL REQUEST for EMERGENCY. Actually the only thing that is different seems to be the RA value.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19198 BTS_Tests: extend rach content tests with emergency call

Actions

Copy link

Updated by dexter almost 4 years ago

On the BTS side I have now added a test that does a channel activation/release with a RA that indicates an emergency call.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19203 BSC_Tests: extend TC_chan_act_ack_noest with emergency call

This test also passes when "allow-emergency" is set to "deny". My first guess here is that osmo-bsc lacks a check that checks the RA. (An MS should not even try to do an emergency call if emergency calls are forbidden, it detects that by looking at the SYSTEM INFORMATION TYPE 3 messages. What we want to simulate is basically a spec-violating MS). However, I have a question here. From what I can see it is not possible to reject the CHANNEL RQD. We need to go through the entire IMMEDIATE ASSIGNMENT procedure and then immediately relase the channel agein. The cause code might be "Preemptive release". I am not sure if this is correct but I think so since the RA is used the first time in the IMMEDIATE ASSIGNMENT message. Also the MS does not have a channel yet, so there is no way to tell it to go away. Alternatively we could just ignore the CHANNEL RQD. but I think that is not the correct way, it would only delay the EMERGENCY call, which can be deadly.

Actions

Copy link

Updated by dexter almost 4 years ago

Checklist item BTS_Tests.ttcn test sending RACH request for EMERGENCY set to Done

Actions

Copy link

Updated by laforge almost 4 years ago

On Thu, Jul 09, 2020 at 01:23:58PM +0000, dexter [REDMINE] wrote:

This test also passes when "allow-emergency" is set to "deny". My first guess here is that osmo-bsc lacks a check that checks the RA. (An MS should not even try to do an emergency call if emergency calls are forbidden, it detects that by looking at the SYSTEM INFORMATION TYPE 3 messages. What we want to simulate is basically a spec-violating MS).

correct.

However, I have a question here. From what I can see it is not possible to reject the CHANNEL RQD. We need to go through the entire IMMEDIATE ASSIGNMENT procedure and then immediately relase the channel agein. The cause code might be "Preemptive release". I am not sure if this is correct but I think so since the RA is used the first time in the IMMEDIATE ASSIGNMENT message. Also the MS does not have a channel yet, so there is no way to tell it to go away. Alternatively we could just ignore the CHANNEL RQD. but I think that is not the correct way, it would only delay the EMERGENCY call, which can be deadly.

there is an IMMEDIATE ASSIGN REJECT that can be used to reject any RACH request. It's normally
used on congestion of channels, but I think we should also use it here.

If the network advertises no emergency call support, then it does that for a reason (e.g. because
it is a private network with no connection to emergency providers). We should not accept any
emergency calls if this feature is disabled.

So I think IMMEDIATE ASSIGN REJECT is the way to go here.

Actions

Copy link

Updated by dexter over 3 years ago

Checklist item BSC_Tests.ttcn test handling CHAN RQD (BSC expeted to reject if "allow-emergency deny"; channel activation otherwise) set to Done
Checklist item BSC_Tests.ttcn test handling EMERGENCY SETUP (BSC expected to reject if "allow-emergency deny", pass to A otherwise) set to Done

Actions

Copy link

Updated by dexter over 3 years ago

% Done changed from 10 to 90

osmo-bsc now blocks emergency calls also when the CHAN RQD is indicating an emergency call when emergency calls are disabled for the BTS. There is also now a TTCN3 test to verify that. The following patches are now in review:

TTCN3:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19578 BSC_Tests: fix TC_chan_act_ack_noest_emerg
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19579 BSC_Tests: Make sure CHAN RQDs for emergency are denied

osmo-bsc:
https://gerrit.osmocom.org/c/osmo-bsc/+/19580 abis_rsl.c: make sure emergency calls are rejected early
https://gerrit.osmocom.org/c/osmo-bsc/+/19565 gsm_04_08_rr: block EMERGENCY SETUP when EMERGENCY CALLS are denied

Actions

Copy link

Updated by dexter over 3 years ago

Status changed from In Progress to Resolved
% Done changed from 90 to 100

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

Cellular Network Infrastructure » Radio Access Network » OsmoBSC

Custom queries

Feature #4548

automatic test coverage for emergency call support on osmo-bsc

Updated by dexter almost 4 years ago

Updated by dexter almost 4 years ago

Updated by dexter almost 4 years ago

Updated by dexter almost 4 years ago

Updated by laforge almost 4 years ago

Updated by dexter over 3 years ago

Updated by dexter over 3 years ago

Updated by dexter over 3 years ago