Cellular Network Infrastructure » Radio Access Network » OsmoBTS

It seems it's actually expected that this scenario occurs, the specs talk about it:

For PCCCH, in TS 44.060 7.2.1.1

"The allocated radio resource is assigned to the mobile station in a PACKET DOWNLINK ASSIGNMENT message to
the mobile station. The PACKET DOWNLINK ASSIGNMENT message is transmitted on the PCCCH timeslot
corresponding to the PCCCH group the mobile station belongs to. The appropriate PCCCH group is calculated from the
IMSI (see 3GPP TS 45.002). The behaviour of the network when the IMSI is not provided by the upper layers is
implementation dependent for the calculation of the PCCCH group where the PACKET DOWNLINK ASSIGNMENT
message has to be sent" 

For CCCH, in TS 44.018 3.5.3.1.2 "Initiation of the packet downlink assignment procedure":

The network initiates the packet downlink assignment procedure by sending an IMMEDIATE ASSIGNMENT or
IMMEDIATE PACKET ASSIGNMENT message (if supported) in unacknowledged mode on the CCCH timeslot
corresponding to CCCH group the mobile station belongs to. The appropriate CCCH group is calculated from the IMSI,
see 3GPP TS 45.002. The behaviour of the network when the RR entity does not receive the IMSI from the upper layers
is implementation dependent for the calculation of the CCCH group where the IMMEDIATE ASSIGNMENT or
IMMEDIATE PACKET ASSIGNMENT message has to be sent. If the mobile station is in non-DRX mode or if the RR
entity does not receive the IMSI or the DRX parameters from the upper layers, there is no further restriction on what
part of the downlink CCCH timeslot the IMMEDIATE ASSIGNMENT, or IMMEDIATE PACKET ASSIGNMENT
message, or the first part of the IMMEDIATE ASSIGNMENT message (in the case of a two-message assignment), can
be sent. If the mobile station applies DRX, the IMMEDIATE ASSIGNMENT, or IMMEDIATE PACKET
ASSIGNMENT message, or the first part of the IMMEDIATE ASSIGNMENT message (in the case of a two-message
assignment), shall be sent in a CCCH block corresponding to a paging group determined for the mobile station in packet
idle mode, see 3GPP TS 45.002. If the mobile station has negotiated the use of eDRX, the IMMEDIATE
ASSIGNMENT or IMMEDIATE PACKET ASSIGNMENT message shall be sent in a CCCH block corresponding to a paging group determined for the mobile station in packet idle mode according to the lowest eDRX cycle, see
3GPP TS 45.002.

DRX is specified here: TS 44.060 5.5.1.5 "Discontinuous reception (DRX)". There even seems to be a specific about the scenario we are observing:

4) When initiating the MM procedures for GPRS attach and routeing area update defined in 3GPP TS 24.008, the
mobile station shall enter the MM non-DRX mode period. This period ends when either of the messages GPRS
ATTACH ACCEPT, GPRS ATTACH REJECT, ROUTING AREA UPDATE ACCEPT or ROUTING AREA
UPDATE REJECT is received by the mobile station. This period also ends after timeout when waiting for any of
these messages

dexter please have a look at the previous behavior before your patches in osmo-bts, to figure out what was osmo-bts doing before when the ImmAss was being used without IMSI.

while investigating current DRX support, I submitted a missing update of DRX Params in osmo-sgsn:
https://gerrit.osmocom.org/c/osmo-sgsn/+/33753 gmm: Update DRX params during rx RAU REQ

3GPP TS 48.018 6.1 "Downlink UNITDATA procedure"

The SGSN shall include the IMSI in the PDU. As an exception, the SGSN may omit the IMSI in the PDU if the mobile
station identified by the TLLI is in MM non-DRX mode period (i.e. during a GMM procedure for GPRS attach or
routing area updating defined in 3GPP TS 24.008) and the SGSN does not have a valid IMSI.

If the SGSN has valid DRX Parameters for a TLLI, then the SGSN shall include them in the PDU. Nevertheless, the
SGSN can omit the DRX Parameters if the MS identified with the TLLI is in MM non-DRX mode period to speed up
the transmission of the LLC-PDU on the radio interface. The SGSN shall not send a DL-UNITDATA PDU without the
DRX Parameters IE if the MS identified with the TLLI is not in MM non-DRX mode period.

3GPP TS 45.002 6.5.3 "Determination of specific paging multiframe and paging block index"

[... here explains how to calculate the Rx based on paging group...]

In GPRS non-DRX mode, the MS shall listen to all blocks of the CCCH channel.

Again, in section 6.5.6 "Determination of PCCCH_GROUP and PAGING_GROUP for MS in
GPRS attached mode":

In non-DRX mode, depending whether there is or not PCCCH channel(s) in the cell, the MS shall listen :
- to all M blocks per multiframe where paging may appear on a PCCCH channel, or
- to all blocks on a CCCH channel.
In DRX mode, the MS shall listen to the blocks corresponding to its paging group as defined by the different
PAGING_GROUP values.

Some extra notes on possible optimizations which involve reworking/updating PCUIF:

<pespin> I'm not actually sure if the DRX feature can be used to "shorten" the amount of time listening on PCH (improve latency) or to "extend" it (improve battery life), or any of those can be configured
<pespin> In any case, MS enters non_DRX mode period during "the transition from the packet transfer mode to the packet idle mode". Which means we could in general improve latency of reaching the MS on AGCH to assign a DL TBF if we account for the drx_params that we assigned to the MS (which we know at PCU)
<pespin> we probably need to update/rework the tx_pch_dt to pass DRX information so that the BTS has more info on where it can schedule the message. For instance, pass to the BTS a timeout in seconds after which the pkt must be sent over PCH/pgroup; before it times out it can be sent on AGCH

As we discussed in the chat I have now changed bts.cpp so that it sends the IMMEDIATE ASSIGNMENT via AGCH in case no IMSI is available. This alone may not be enough though since now osmo-bts will not send any confirmation for this immediate assignment. I am not entirely sure, but the downlink tbf may expect the confirmation in order to move on. We might now confirm IMMEDAIATE ASSIGNMENTs for dl TBFs in osmo-bts (and osmo-bsc, which will not very timing accurate) now.

https://gerrit.osmocom.org/c/osmo-pcu/+/33768 bts: send IMMEDIATE ASSIGNMENT via AGCH when no IMSI is available

dexter wrote in #note-8:

As we discussed in the chat I have now changed bts.cpp so that it sends the IMMEDIATE ASSIGNMENT via AGCH in case no IMSI is available.

pespin dexter are you sure this is the right thing to do? The MS does not need to listen to AGCH all the time, unless it has initiated a channel request procedure. So if the PCU would be sending DL TBF assignment over AGCH, it will most likely be ignored. I am not 100% sure, but this is my understanding.

fixeria wrote in #note-9:

dexter wrote in #note-8:

As we discussed in the chat I have now changed bts.cpp so that it sends the IMMEDIATE ASSIGNMENT via AGCH in case no IMSI is available.

pespin dexter are you sure this is the right thing to do? The MS does not need to listen to AGCH all the time, unless it has initiated a channel request procedure. So if the PCU would be sending DL TBF assignment over AGCH, it will most likely be ignored. I am not 100% sure, but this is my understanding.

See the full quotes of different specs above regarding (non-)DRX. The case where no IMSI is present/known is the case where the MS is expected to be in non-DRX mode as per specs (during GMM Attach procedure). Hence, it will be listening to all blocks in CCCH. So it's fine to assume that if PCU sends use a PCH block with no imsi, it can be transmitted over AGCH. Ideally we'd need to select another SAPI from osmo-pcu, but applying this in existing PCH will also improve the situation for osmo-bts running against older osmo-pcu versions with a minimal change.

pespin wrote in #note-10:

See the full quotes of different specs above regarding (non-)DRX. The case where no IMSI is present/known is the case where the MS is expected to be in non-DRX mode as per specs (during GMM Attach procedure). Hence, it will be listening to all blocks in CCCH. So it's fine to assume that if PCU sends use a PCH block with no imsi, it can be transmitted over AGCH. Ideally we'd need to select another SAPI from osmo-pcu, but applying this in existing PCH will also improve the situation for osmo-bts running against older osmo-pcu versions with a minimal change.

"Hence, it will be listening to all blocks in CCCH" -- but DRX is all about PCH, isn't it? AFAIU, entering non-DRX mode means listening to all PCH blocks. There is simply no reason for an MS to keep listening to AGCH unless it's actually expecting a resource assignment in response to its prior request. This is not the case for DL TBF assignment because the MS cannot make assumptions if and when the network is going to assign it. Even if it works fine with some UEs, there is still a risk that some baseband vendors implemented this differently.

Wouldn't it be enough to modify osmo-bts, so that it simply sends DL TBF assignment blocks on PCH without IMSI as soon as possible?

fixeria wrote in #note-11:

pespin wrote in #note-10:

See the full quotes of different specs above regarding (non-)DRX. The case where no IMSI is present/known is the case where the MS is expected to be in non-DRX mode as per specs (during GMM Attach procedure). Hence, it will be listening to all blocks in CCCH. So it's fine to assume that if PCU sends use a PCH block with no imsi, it can be transmitted over AGCH. Ideally we'd need to select another SAPI from osmo-pcu, but applying this in existing PCH will also improve the situation for osmo-bts running against older osmo-pcu versions with a minimal change.

"Hence, it will be listening to all blocks in CCCH" -- but DRX is all about PCH, isn't it?

https://osmocom.org/issues/6097#note-4 "the MS shall listen: [...] - to all blocks on a CCCH channel."

AFAIU, entering non-DRX mode means listening to all PCH blocks. There is simply no reason for an MS to keep listening to AGCH unless it's actually expecting a resource assignment in response to its prior request.

The probability it expects a DL TBF is high, hence why it listes on AGCH, to improve latency and avoid overloading PCH.

This is not the case for DL TBF assignment because the MS cannot make assumptions if and when the network is going to assign it. Even if it works fine with some UEs, there is still a risk that some baseband vendors implemented this differently.

The specs above are quite clear imho, the MS should conform to that.

Wouldn't it be enough to modify osmo-bts, so that it simply sends DL TBF assignment blocks on PCH without IMSI as soon as possible?

Yes, that was the 2nd step I was looking for too (1st step is reverting the behavior of not assigning no-imsi to paging group 0). Third step is to look at improving even further by submitting proper SAPI from osmo-pcu, potentially with extra DRX-related parameters.

dexter please update the state of this ticket to refelect what's osmo-bts doing nowadays after your latest fixes.

Osmo-bts currently uses paging group 0 in case the paging group cannot be determined due to the missing IMSI, so those ImmAss messages are no longer dropped.

When the IMSI is not known (null-string), then the PCU will not send the ImmAss[PktDlAss] through the PCH. Instead it will send it through the AGCH. (see also bts_snd_dl_ass() in bts.cpp.

(If for some reason someone tries to send a MAC block through the PCH without an IMSI, then paging group 0 is used, but that shouldn't happen)

dexter wrote in #note-16:

(If for some reason someone tries to send a MAC block through the PCH without an IMSI, then paging group 0 is used, but that shouldn't happen)

My expected behavior is that if the client is using V10, then the PCU still sends the back block over PCH with an empty IMSI (because AGCH is not implemented in v10 afaiu). Correct?

Yes, that is correct.