Feature #5781
closedFeature #4851: VCGS/VBS support in osmo-bts
NCH support in osmo-bts
Added by laforge over 1 year ago. Updated 8 months ago.
100%
Description
In order to support ASCI, we need to support transmission on the downlink NCH.
This includes- decoding the related commands on Abis RSL
- reserving one of the SDCCH/4 or SDCCH/8 as NCH (similar to CBCH)
- transmission of NCH messages in downlink
- re-transmission of NCH messages at least once per second until call ends (see "ASCI OPTIONS FOR OPERABILITY")
Updated by laforge 12 months ago
actually, the NCH is part of the normal Downlink CCCH, so no additional SDCCH is occupied.
Relevant quotes from TS 45.002:
3.3.3.1 iv): Notification channel (NCH): Downlink only, used to notify mobile stations of voice group and voice broadcast calls.
6.4.1 NOTE 0: CCCH = PCH+ RACH + AGCH + NCH.
6.3.1.3 ii): System Information Type 1 needs to be sent if frequency hopping is in use or when the NCH is present in a cell.
The PCH, AGCH, NCH and BCCH Ext may share the same TDMA frame mapping (considered modulo 51) when combined onto a basic physical channel. The channels are shared on a block by block basis, and information within each block, when de-interleaved and decoded allows a mobile to determine whether the block contains paging messages, notification message, system information messages or access grants. However, to ensure a mobile satisfactory access to the system a variable number of the available blocks in each 51-multiframe can be reserved for access grants and system information messages, only. The number of blocks not used for paging (BS_AG_BLKS_RES) starting from, and including block number 0 is broadcast in the BCCH (see subclause 3.3.2). As above the number of paging blocks per 51-multiframe considered to be "available" shall be reduced by the number of blocks reserved for access grant messages.
6.5.1 vii) An MS which has its membership of at least one voice group or voice broadcast call group set to the active state shall, in addition to monitoring the paging blocks as described above, monitor the notification channel, NCH. This logical channel is always mapped onto contiguous blocks reserved for access grants, in a position and number as given by the parameter NCP, defined in 3GPP TS 44.018, broadcast on the BCCH. The channel may be present when a cell supports voice group or voice broadcast calls. The coding of the various structural parameters described above in this subclause is not changed. Information within a block, when deinterleaved and decoded, allows the MS to determine whether the block contains access grant messages or notification messages.
6.5.5: When mobile stations are to be alerted on a voice group or voice broadcast call, notification messages shall be sent on the notification channel (NCH), using the blocks defined in subclause 6.5.1.
When the NCH is in use, the parameter BS_AG_BLKS_RES shall be set to a value not lower than the number of blocks used for the NCH, see subclause 6.5.1 vii) [above].
Updated by laforge 12 months ago
The detailed position of the NCH within the downlink CCCH is encoded in the SI1 Rest Octets, as described in TS 44.018 Table 10.5.2.32.1b:
NCH Position on the CCCH
The values in the NCH Position field indicates the block number of the CCCH block which is used for the first NCH block and the number of blocks used for the NCH. (The block numbering corresponds to table 5 in clause 7 of 3GPP TS 45.002)
The absence of the NCH position field indicates that there is no NCH in the cell/on the carrying CCCH slot
The following coding applies if 1 or more basic physical channels are used for CCCH, not combined with SDCCHs.
| Value | No of blocks | Number of first block |
|---|---|---|
| 0 0 0 0 0 | 1 | 0 |
| 0 0 0 0 1 | 1 | 1 |
| 0 0 0 1 0 | 1 | 2 |
| 0 0 0 1 1 | 1 | 3 |
| 0 0 1 0 0 | 1 | 4 |
| 0 0 1 0 1 | 1 | 5 |
| 0 0 1 1 0 | 1 | 6 |
| 0 0 1 1 1 | 2 | 0 |
| 0 1 0 0 0 | 2 | 1 |
| 0 1 0 0 1 | 2 | 2 |
| 0 1 0 1 0 | 2 | 3 |
| 0 1 0 1 1 | 2 | 4 |
| 0 1 1 0 0 | 2 | 5 |
| 0 1 1 0 1 | 3 | 0 |
| 0 1 1 1 0 | 3 | 1 |
| 0 1 1 1 1 | 3 | 2 |
| 1 0 0 0 0 | 3 | 3 |
| 1 0 0 0 1 | 3 | 4 |
| 1 0 0 1 0 | 4 | 0 |
| 1 0 0 1 1 | 4 | 1 |
| 1 0 1 0 0 | 4 | 2 |
| 1 0 1 0 1 | 4 | 3 |
| 1 0 1 1 0 | 5 | 0 |
| 1 0 1 1 1 | 5 | 1 |
| 1 1 0 0 0 | 5 | 2 |
| 1 1 0 0 1 | 6 | 0 |
| 1 1 0 1 0 | 6 | 1 |
| 1 1 0 1 1 | 7 | 0 |
Other values are reserved for future use. A mobile station receiving a reserved value shall behave as if the NCH position was not present
In the case the CCCH configuration is not compatible with the NCH position (e.g., CCCH with combined SDCCH and the value different from 00000, 00001 or 00111), the mobile station shall behave as if the NCH Position field was not present.
Updated by laforge 12 months ago
- Status changed from New to In Progress
- Assignee set to laforge
- % Done changed from 0 to 10
In general, it turns out that we don't even actually need a NCH. It seems entirely optional.
In absence of a NCH, the related notification messages are sent via PCH (P1 rest octets).
In any case, let's implement basic NCH suport so we can test sending notification messages both via NCH and via PCH.
There's also a path to send notification via FACCH to those MS that are currently in a dedicated call. This has to be implemented in the BSC, though.
Updated by fixeria 11 months ago
I am seeing error messages like this one:
DNM ERROR osmo_bsc_main.c:399 (bts=0) CCCH is combined with SDCCHs, but NCH position/size is incompatible with that. Please fix your config!
since this commit was merged:
https://gerrit.osmocom.org/q/Iefde0af44a663f22462a54d68a58caa560eceb2f
commit 8798689f3bc737c1f1d2da58803673a05291ee72
Author: Harald Welte <laforge@osmocom.org>
Date: Mon May 8 06:59:55 2023 +0200
Support (optional) indication of NCH position in SI1 rest octets
The problem is that my config file contains no NCH position/size configuration at all...
Updated by fixeria 8 months ago
fixeria wrote in #note-5:
I am seeing error messages like this one: [...]
The bogus error message has been fixed by this patch:
commit 6153c619fcf5f7b31edb6cc49cb3f1331e011ac3
Author: Harald Welte <laforge@osmocom.org>
Date: Wed Jun 21 11:46:15 2023 +0200
prevent bogus NCH related error message if no NCH is configured
