diff options
author | Vadim Yanitskiy <axilirator@gmail.com> | 2019-09-30 20:43:11 +0700 |
---|---|---|
committer | Vadim Yanitskiy <axilirator@gmail.com> | 2019-09-30 20:50:28 +0700 |
commit | 5516b423365cc4ad9a6f37e3676126f149591490 (patch) | |
tree | dd3642a1ecdfaea36b52d7934001b714c08fb66c /src/host/gsmmap | |
parent | a2ac6d67242ca96593b4f0c4aebd49b4c34eff44 (diff) |
trxcon/scheduler: fix handling of PTCCH logical channel
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - it has nothing to do with xCCH coding. Instead, we need
to use rx_pdtch_fn() for Downlink and tx_rach_fn() for Uplink.
Also, since we only have a shared RSL channel number for PDCH
(Osmocom-specific RSL_CHAN_OSMO_PDCH), there should be a way
to distinguish both PDTCH and PTCCH logical channels. Let's
introduce TRX_CH_LID_PTCCH for that.
Change-Id: I2d1e9b8a66f027047f8d7bdc3f82ff9d8ebcc25e
Diffstat (limited to 'src/host/gsmmap')
0 files changed, 0 insertions, 0 deletions