continuous timing advance loop using PTCCH
We currently only implement the "initial TA" where the TA of a MS is determined at time the TBF is established. If the MS moves more than 1 TA during a TBF being active, this leads to problems.GPRS has the PTCCH for this, a special channel in the PDCH channel combination multiplex, using which we can instruct a sub-set of 16 MS (whether TBFs are active or not) to adjust their timing advance continuously. What needs to be done is
- code to generate the PTCCH/D messages
- code to parse the PTCCH/U messages
- code to determine which 16 MS will be part of the current PTCCH subset
- unit tests for the above
We also need to see how we can test this with actual hardware, in a way that TA exists (and changes) over time. Unfortuantely we don't have a MS-side GPRS implementation for OsmocomBB, because then we could simply artificially delay the transmit burst timing to make the network determine a higher TA.
#10 Updated by msuraev almost 4 years ago
According to 3GPP TS 45.002 § 188.8.131.52.2 PTCCH/U is allocated on one of the TS where PDTCH are allocated to the MS. MS will send RACH in there. PTCCH/U have subchannels (0...15) assigned to different MS using TAI. PTCCH/D allocation is in Clause 7 Table 6 in the same spec. PTCCH/D frames are encoded using CS-1.
- % Done changed from 0 to 20
Please see: https://gerrit.osmocom.org/r/I887c8922446d0c1a959e6f2678f50e5754f55e83 and https://gerrit.osmocom.org/r/I868f78e3e95a95f8f2e55e237eea700d7d4726a3. IMHO, it should be rather easy to implement this feature. I see a potential implementation as a class (e.g. PTCCHControl) that will provide the following methods:
/* Obtain an unused TA Index for a TBF */ uint8_t PTCCHControl::obtain_tai(void); /* Mark a given TA Index as free, so it can be used again */ void PTCCHControl:release_tai(uint8_t tai); /* Update the actual Timing Advance value for a given TA Index */ void PTCCHControl:update_ta(uint8_t tai, int16_t toa); /* Generate a to be transmitted PTCCH/D block (23 octets) */ void PTCCHControl:gen_ptcch_msg(uint8_t buf);
Therefore each time-slot object should be associated with an instance of PTCCHControl.
- % Done changed from 20 to 80
I could not resist :D The only missing part now is TAI assignment on TBF allocation.
Also, while testing this branch I found several problems in my TTCN-3 test case:
Also, there is a problem in the PCU interface: RACH.ind message does not contain TRX / TS number fields.
We may have multiple PDCH time-slots on multiple transceivers, and we need to know the origin of Access Bursts on PTCCH/U.