Before we add handling of TCH I/O for data calls, let's rename the
existing voice related symbols and struct fields to have 'voice'
in their names.
Change-Id: If6c799d11e225ad00ca5da5ae63dca20568a0ce0
Related: OS#4396
This patch implements the signalling part for mobile originating
and mobile terminating CSD calls. The user plane interface is
to be implemented in follow-up patches.
Change-Id: I1995fa0a7a68d9b980852b664d472d4633777ac6
Related: OS#4396
This option must be enabled in the VTY and is disabled by default.
Calls can be joined when service is limited or normal. With that option
enabled, calls can be joined even with invalid SIM.
Talking is allowed when service is normal. With that option enabled,
talking is always allowed. It depends on the network, if it accepts the
talker.
Change-Id: I6ea851a8cb015ff685b985335968c6184beca816
Related: OS#5364
Use TMSI only if valid in the current location area. If the MS moves to
a different location area and joins a group call before location update,
TMSI is not valid. Then use IMSI instead. If no IMSI/TSMI is available,
send mobile identity without IMSI/TMSI.
Change-Id: I299604a0e12d91e9133b70757826ac9637da0e3e
Related: OS#5364
If joining a call gets rejected, the call must not be released, instead
it must return to U3 state (incoming call), because the call still
exists in the cell and it might possible to join it later.
If a call notification is gone, a new event is used in the state machine
to release incoming call.
Change-Id: I605387c6be409ef0e67caf7b9e2a83e1032b45f1
Related: OS#5364
This patch prepares for adding MT data call support:
* Move handling of the Bearer Capability IE into a function.
* Check transfer mode and coding standard in the received BCap.
Change-Id: I3a5cac8c35ba6b7bdc5fcb077690b32848747756
Related: OS#4396
Even though the function works as expected and *can* return -1,
which is first casted to unsigned and then back to signed, let's
make the code less confusing by returning -1 straightaway.
Change-Id: I3206fcfa9ab4cac85a1f0f2a4de3250b25f9058f
Related: OS#4396
Use new_mm_state() to leave group mode. This will trigger IMSI detach
when returning to IDLE mode, if it has been delayed.
Related: OS#5364
Change-Id: I3c83c9e0fe10b35d60d125df6929fcb5ddc35f1a
Cell selection is not supported during group receive mode. If it
happens anyway, give an error message and select correct sub-state.
This fixes I05957182a57423ad947ab200b52f65fde859e110.
Related: OS#5364 and OS#6214
Change-Id: Iea6fe623956003130000c59ec0e1b24b3177052d
These states are:
GSM48_MM_SST_NORMAL_SERVICE
GSM48_MM_SST_ATTEMPT_UPDATE
GSM48_MM_SST_LIMITED_SERVICE
GSM48_MM_SST_LOC_UPD_NEEDED
GSM48_MM_SST_PLMN_SEARCH (limited service)
GSM48_MM_SST_PLMN_SEARCH_NORMAL
If the service is limited, group/bcast calls can be joined, but uplink
access is not allowed.
Related: OS#5364
Change-Id: I2f8ff65f6e101972f9b1760013983d00ae6e7760
The loopback mode is currently broken because the DL info header
remains present, thus becoming a bogus "part" of the speech frame.
Change-Id: I1af187b4bc5f5a99bc7f7634d90bf14ad3db0e49
Related: OS#4396
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 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
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
This commit fixes recent previous commit filling in the fn field. The
dl->frame_nr is network order, and we want to pass a host order integer
in the primitive. Use the tm.fn which already includes the proper value
calculated from dl->frame_nr.
Fixes: d524c17d90
Related: OS#3626
Change-Id: Id96015c8b419932abb8095c6cb85aceef34e366f
The pointer and size must given for the SV portion of the character
array only.
Fixes: CID#314049, CID#314048
Change-Id: Ieff4ca886dec71aae1b6ecf2b623d600426580da
During initial GMM Attach, the GMM layer generates an internal
local TLLI and uses it to do the GMM Attach. Only at the time it
receives the GMM Attach Accept with the assigned TLLI from the network
then explicitly informs other layers about the TLLI update.
Hence, the GMMREG user doesn't really know about the TLLI in use until
the GMM Attach success happens (gmmreg-attach.cnf).
During that time, the TLLI at the app is basically unassigned
(0xffffffff). Hence, during that same time a TLLI update hook in
GMMRR-Assign.req will not work since the app is unaware of the remporary
local TLLI, so no match can be done.
In that specific scenario, that's fine, since anyway it is waiting to
receive the GMMREG-Attach.cnf, which will indicate the assigned TLLI to
it.
In summary, not being able to match the TLLI in GMMRR-Assign.req is not
bad per se, so soften the log error there.
Change-Id: I31c04288789393391084000fbdbcdcedb11d0b68
Right now the existing code is switching to state IDLE and hence running
grr_st_packet_idle_onenter() which attempts stuff like starting an attach.
This is all done while the L1CTL RESET + FBSB is still in progress. We
should instead wait to receive confirmation from those.
As an easy implementation for now, simply switch to the
GRR_ST_PACKET_NOT_READY state, which will move to GRR_ST_PACKET_IDLE
once it starts receiving CCCH blocks (aka it will already have gone
through L1CTL RESET + FBSB completely).
Change-Id: Ie797b36701d10c6052500c637a08b061bb1e4bd7
Signal RLC/MAC layer that the lower layers is in packet idle mode ready
to use CCCH (such as packet-access-procedure).
Change-Id: I05050e840a3b267b3b3a278588ee113b45bfbd4c
This is needed in order to provide updated TLLI when submitting new user
data from the tundev to the SNDCP layer.
Change-Id: I5c6a2c371ae6d65bf4fe23e665ec939da37112be
We need to distinguish between Uplink and Downlink TBF assignment in
grr_rx_imm_ass(), because matching the Request Reference IE makes
sense only for the Uplink TBF assignment.
Uplink TBFs are requested by the UEs by sending RACH, while Downlink
TBFs are assigned by the network itself. The Request Reference IE
is only valid for Uplink assignments and shall be ignored in messages
assigning Downlink TBFs.
Change-Id: Idb9b3203147be3b42256c0bcab3ecdabcf2d2fa9
Related: OS#5500
In change 67943df4 I broke handling of the logging category mask in
the mobile app. Adding this option results in a segfault:
ERROR: osmo_log_info == NULL! You must call log_init() before
using logging in log_parse_category_mask()!
Assert failed osmo_log_info src/libosmocore/src/core/logging.c:329
As can be seen, the problem is that we are calling
log_parse_category_mask() before initializing the logging.
As possible solution, I could rearrange the code to parse command
line options after calling osmo_init_logging2(). This would fix
the segfault, but would not fully solve the problem.
If we call log_parse_category_mask() before parsing the config file,
then logging configuration in the config file overwrites the logging
configuration specified via the command line. But we want the
opposite: the command line setting should overwrite the config file
parameters. This is handy because there is no need to edit the
config file if you quickly need to test something.
So let's call log_parse_category_mask() after parsing the config file.
Change-Id: I1b2b7804bf99b71f96e9197f7824cfd20431e8a1
Fixes: 67943df4 "layer23: fix parsing of command line options"
libosmogsm has recently deprecated the use of osmo_auth_gen_vec
and the osmo_sub_auth_data structure in favor of newer versions
of this API. Let's migrate to it
Change-Id: I1d9751c5f74a59e7310d07d54a3fdbac213324bd
Depends: libosmocore.git Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
Found by clang:
gsm48_cc.c:54:6: warning: logical not is only applied to the left
hand side of this comparison [-Wlogical-not-parentheses]
if (!cc->mncc_upqueue.next == 0)
^ ~~
Change-Id: Ic7ffd3aa25339e24a31bae1b7428f1f93e261858
The RLCMAC layer in libosmo-gprs-rlcmac will decode the messages and if
matching the MS, forward it to GMM, who will see if it requires initiating
a packet access procedure.
Change-Id: Iee4b5ee5e1e5874b550dd8536b095bf0b5eeb8f4
Vadim Yanitskiy
Andreas Eversberg
Andreas Eversberg
Pau Espin
Harald Welte