Note that despite the VTY interface offers various channel type
filtering facilities, the actual filtering is not implemented.
This patch simply brings PS domain in consistency with CS domain:
the UL and DL GPRS blocks are now being sent over GSMTAP without
any filtering, just like GSM MAC blocks.
Change-Id: I338205bee44fe182233efc5619a3d528cd07d932
Related: OS#5500, OS#6209
Even if follow-on proceed is not supported, the warning message about
not beeing supported should only show when the follow-on proceed
information element is included in the location update accept messages.
Change-Id: I2b1aceb8b85bdd9faabe354501f9036f1fc6fe33
The order of ARFCNs are described in TS 44.018 §10.5.2.20.
The function arfcn_from_freq_index() is re-used to get the ARFCNs in
correct order for the report.
Change-Id: I0674467eb5a38a341cf65f95a25aa5f7232df069
The selection of ARFCN is described in TS 44.018 §10.5.2.20.
The frequencies found in SI5 and SI5bis are counted first, in the
following order: ARFCN 1..1023,0.
The frequencies found in SI5ter are counted afterwards, in the following
order: ARFCN 1..1023,0.
Related: OS#5782
Change-Id: I090d84a5550d89743e8f5a886f400df6483f50d7
I forgot to permit the loop state transmission, so the modem app
gets stuck in GRR_ST_PACKET_ACCESS is no IMM ASS is received...
Change-Id: I059d2929f7f724cfe26935bf35c167e60157451f
Fixes: 9978b00e "modem: grr: implement RACH.req retransmission"
The "support" flags must be copied to the settings, because they are
enabled by default and may be omitted in the VTY config.
Related: OS#5364
Change-Id: I81575dd3f2ade70101df32935a1c3d5469327577
Get rid of goto and double switch/case by putting connection handling
code into a separate function.
Change-Id: I12454cab06c105ccd9e2495e3a6f0640f2884885
This is required, because different protocols may share the same
callref, but use different protocols. E.g. a voice group call can share
the same callref with a voice broadcast call, but these calls are
different transactions.
Related: OS#5364
Change-Id: Ifea3a81aae3b4ae897851f867b13fa987c8cbe11
This allows the upper layer to estabish and release connection on the
uplink of a voice group call.
Related: OS#5364
Change-Id: I9b62eef5d877e5d9dcf349717efd2cce28862c58
This allows reception of VGCS and VBS calls. A special sub-state is used
to differentiate between IDLE mode and group receive mode. Later it can
be used to differentiate between dedicated and group transmit mode.
Related: OS#5364
Change-Id: Ia7d806b354fb3be5729bff8ac9aa1c7ad7a8b539
The gsm48_rr_rx_acch function receives FACCH/SACCH. This is not only
used for system information on SACCH, but also for short header messages
and regular UI messages on TCH.
Related: OS#5364
Change-Id: I39b27396a31137b3c4bdcb40dccdf3de60458fe2
The patch "ASCI: Add GCC/BCC (call control) to mobility management"
breaks reception of MM messages. No MM connection setup is possible.
This patch fixes the issue.
Change-Id: I263739bb0220d19f14114714fe9d82505bdbd267
This patch includes new messages and description. The are used to bring
RR layer into group receive mode and from there in group transmit mode
and back.
Related: OS#5364
Change-Id: I1abd56c63d15af1cff8bde7589a571cb5bb5506f
This is required to notify MM layer about new and ceased group and
broadcast calls.
Related: OS#5364
Change-Id: Ifee286ba4628356cc19b5dc75f1843287c5d2342
The gsm48_rr_hdr is pushed into the message before sending data to
MM layer. SAPI was not set in this header.
Change-Id: I8345a562050d52d491f3b7192c979d455a63931c
Do not overwrite the given request reference pointer with the history
buffer's reference. This makes no sense.
Without this fix only the response to the first access burst could be
matched correctly.
Change-Id: Iec636d368e20030beac2861bff61b1a06e7b4821
3 entries are enough for random access on CCCH. 5 are required for
uplink request on VGCS channel.
The history is used to remember when the random access bursts were send.
The RR layer can check if the IMMEDIATE ASSIGNMENT or VGCS UPLINK GRANT
message has matching frame number and random value of up to 5 random
access bursts previously sent.
Related: OS#5364
Change-Id: I62f18685bf05663f3ee6e94f6884ffb9a6b07ea4
Deprecated functions gsm48_generate_mid_from_*() are replaced by
osmo_mobile_identity_encode_msgb(). Clean up code.
Change-Id: I9ff429bd50d718530fdad64a276053a35c8928f2
These support flags can be enabled or disabled and are sent in the
class mark IE. Also they allow or disallow making VGCS/VBS calls.
Related: OS#5364
Change-Id: Ia23eb190e533660cce4ba4c856a83b5f3d534202
A different identity code can be used on uplink access bursts on voice
group channel. This is optional for the network, but mandatory for the
MS side. If the network does not define a UIC, the BSIC is used instead.
BSIC is used for RACH channel and handover.
Related: OS#5364
Change-Id: I4039734676949aefa5be4b5298764b8ba7e1b8ed
This is required to access a TCH during handover or to access the uplink
of a VGCS channel.
The patch is taken from the handover branch.
Change-Id: I1a972d9bac5749c67c1b139825400854f7cf1490
This flag can be used to turn transmitter off for "group receive mode"
or for handover procedure. The flag is stored in the channel description
of the mobile application. It is sent to layer 1 when switching to
dedicated channel or when changing TCH mode.
At the layer 1 the transmitter is turned off while the receiver is still
active. This is done by:
* scheduling a TX dummy task for TCH bursts
* scheduling no TX task for SACCH bursts
* not enabling the transmit window
Related: OS#5364
Change-Id: I20133523adc3b204cd2181bfe664fe66020a10e3
VGCS and VBS calls may share the same (call) ref or share with other
protocols. Therefore the MM connection is defined by the reference and
the prococol discriminator.
Related: OS#5364
Change-Id: Ic280cd8c666660077bb2c2ef641f4cddd3b36eee
Instead of assuming that there are TX power and timing advance IEs
included in RSL message, check for existence.
gsm48_rr_rx_acch() may receive frames from FACCH that do not have these
IEs included in the message. These frames are UI frames on DCCH and Bter
frames. E.g. these frames are used on voice group channel to control
uplink.
Related: OS#5364
Change-Id: I87fcd44bba221ab4c5fbd2c79557db2444a10b88
GCC is the call control for voice group calls, BCC is the call control
for voice broadcast calls.
This patch includes the new message primitives between MM layer and the
GCC/BCC layers.
Related: OS#5364
Change-Id: If6f3cea4b2ca839559596a6ee5a3d169c6d85dbe
Pass size in bytes to memcpy(), not number of elements!
Change-Id: I687435f5458e766d9d61143d6e4255f089fe1caf
Fixes: 6db5f8b9c "modem: get rid of app_data.chan_req, use ms->rrlayer"
Related: OS#5500, OS#6131
When an UL BLOCK.req is received late, i.e. after the first Tx burst
of the respective TDMA Fn was requested by the PHY, a domino effect
can be observed: the stale Tx primitive remains in the queue and
prevents transmission of the next primitive, even if the later was
received in time. This breaks transmission of consecutive UL blocks.
Don't let stale primitives poison the Tx queue: drop them like before,
but keep looking for a primitive with the matching TDMA Fn. If found
a primitive with TDMA Fn past the current one, stop the iteration.
Change-Id: I439615639b8e840b9fd4f3af6934d9f298f32216
Depends: libosmocore.git I9590f2e836fc48650decf1564b6ab46306c4fe2d
Depends: libosmocore.git Ie8bb9c49c6f81b8f4a1766547d6943f9880d1186
Related: OS#5500
Sometimes sending one Access Burst is not enough, so we need to repeat
sending it a few more more times changing the 3 LSBs randomly. This
is what we already do in the mobile app, but not in the modem app.
* Rename GRR_EV_RACH_{REQ,CNF} to GRR_EV_CHAN_ACCESS_{REQ,CNF}.
* Rename VTY command 'grr tx-chan-req' to 'grr start-chan-access'.
* Add an intermediate state GRR_ST_PACKET_ACCESS.
** The GRR_EV_CHAN_ACCESS_REQ transitions to this state.
** One RACH.req gets transmitted when entering this state.
** The GRR_EV_CHAN_ACCESS_CNF confirms transmission of a RACH.req.
** Upon the timeout (300 ms) expiry, a loop state transition happens.
** After 3 loop-transitions, transition to GRR_ST_PACKET_NOT_READY.
Change-Id: Iab6d9147f6e0aeb99239affacf318a3897fd6ffe
Related: libosmo-gprs.git If0de3ed86b1e2897d70183f3b0f4fbfd7d2bda80
Related: OS#5500, OS#6131
Before this patch, the RTS:ind was crafted up in the stack when
receiving the DL_BLOCK.ind. This created some problems since the
internal low level state has to be updated in between signalling
DL_BLOCK.ind and RTS.ind, as there's a fn-advnace of one block between
those 2 signals (hence the timeslot allocation has to be applied at the
time when the fn-advance is applied).
This is actually not fixing the whole issue, since there's several
timeslots and hence the following events will have the internal timeslot updated
during the event in the middle, hence potentially causing problems in the
remaining TS:
DL_BLOCK.ind(FN=N, TS=1), RTS.ind(FN=N+4, TS=1), DL_BLOCK.ind(FN=N, TS=2)
In any case, this decoupling already improves the situation and is step
needed anyway towards fully fixing the problem (by, for instance,
maintaining a timeslot state duplicated both for DL and Ul directions,
since they drive based on differnet FN time (1 PDCH block).
Change-Id: I1494e0aac7555f6e01b4b435b77140afc42c098e
iWOW TR-800 is a packaged GSM modem module based on Calypso+Iota+Rita
chipset; it is fully quadband, and reverse engineering of its PCB
confirms that this module is nothing but a mass-produced version of
the core of TI's legendary Leonardo+ reference platform. The same
module is also known as FreeCalypso Tango - a rebranded version of
the same hardware module with different firmware and a different
Responsible Party for official support.
FreeCalypso HQ is contributing OsmocomBB support for this Calypso
modem module for two reasons:
1) Harm reduction - sooner or later someone in Osmocom universe is
going to run OBB firmware on TR-800 once they lay their hands on
this hardware, and the resulting operation will be less harmful /
closer to correct if we provide the basic board support patch.
2) There exists a large surplus of FreeCalypso Caramel2 development
boards that are based around FC Tango modules. Having this hw
supported by both firmwares will hopefully increase the chances
that these boards will find loving homes, as opposed to continuing
to gather dust in a cardboard box.
Legal and ethical disclaimer: OsmocomBB firmware running on ANY
Calypso+Iota+Rita target is *known*, through confirmed observations
with a measuring instrument (R&S CMU200), to put out radio transmissions
that are *severely out of spec*, and this defect does NOT go away
with the present patch which merely adds support for a different C+I+R
board target. The present patch has been produced as a harm reduction
measure, to reduce (but not to zero) the harm that will be caused
by parties who run OsmocomBB firmware on C+I+R hardware despite having
been advised not to. As the party seeking to reduce rather than cause
that harm, Mother Mychaela and her related business entities explicitly
disclaim all liability for damage that will be caused by parties who
continue running OsmocomBB firmware despite having been repeatedly
advised to switch to manufacturer-approved published-source firmware
instead.
Change-Id: I84d564f052f12a25ea3bfb9c78860e9dc6262be8
Vadim Yanitskiy
Andreas Eversberg
Andreas Eversberg
Pau Espin