Feature #1551
closed
dynamic timeslot allocations (TCH / SDCCH vs PDCH)
Added by laforge about 8 years ago.
Updated almost 8 years ago.
Description
This change affects OsmoBSC/OsmoNITB, OsmoBTS and OsmoPCU.
Basically, the PCU would attempt to use all currently unallocated timeslots, until the BTS receives a channel activation via A-bis, taking away that timeslot from the PCU.
- Related to Feature #1565: Dynamic PDCH / TCH switching: BTS part added
- Due date set to 06/10/2016
- Priority changed from Normal to High
- Priority changed from High to Urgent
- File two_calls_then_gprs_starts_working.nitb.log added
- File two_calls_then_gprs_starts_working.pcapng added
- File two_calls_then_gprs_starts_working.patch added
- % Done changed from 0 to 20
(removed: accidental submission in wrong issue)
- File deleted (
two_calls_then_gprs_starts_working.nitb.log)
- File deleted (
two_calls_then_gprs_starts_working.pcapng)
- File deleted (
two_calls_then_gprs_starts_working.patch)
- % Done changed from 20 to 0
(removing things because I should have posted them in #1565 instead)
If it does, I would appreciate details on how this issue differs from #1565. Thanks!
- Status changed from New to Feedback
- Assignee changed from neels to laforge
Actually, #1565 is the "ip.access compatibility mode".
But please put this issue in context with #1564. Is it an alternative implementation idea,
or is it orthogonal like #1565 to #1564?
- Status changed from Feedback to In Progress
- Assignee changed from laforge to neels
This ticket is the PCU part of #1565, whcih is the BTS part.
I think the PCU already has everything in place needed. If that's the case, simply close the ticket.
- Target version set to Dynamic TCH/H TCH/F PDCH
- Status changed from In Progress to Closed
We do not yet permit dynamic allocation of SDCCH, but the question is how relevant this is.
Also available in: Atom
PDF