• State Not Answered
  • Replies 38 replies
  • Subscribers 71 subscribers
  • Views 6192 views
  • Users 0 members are here
Attachments (7) Download All
Nordic Case Info
  • Case ID: 304680
Options

SO_RAI_NO_DATA still does not cause RRC release

Michal Mühlpachr

Issue is related to  RE: NRF_SO_RAI_NO_DATA does not cause RRC release in SLM/nrf9160 without send 

Just after AT#XSOCKETOPT=1,50 modem should negotiate RRC Release, but it is not the case.

NCS v2.3 nrf9160_1.3.4

Serial LTE Modem, prj.conf changes:
CONFIG_SLM_START_SLEEP=y
CONFIG_SLM_WAKEUP_PIN=6
CONFIG_SLM_INDICATE_PIN=2
CONFIG_SLM_DATAMODE_URC=y
CONFIG_SLM_EXTERNAL_XTAL=y
CONFIG_NRF_MODEM_LIB_TRACE=y

AT dialogue and PPKII measurements:
[PPK2] DUT Powered, Measurement started
   0.13 <RESET> Wed Mar 15 23:56:33 2023
   1.01 [PPK2] 100k/s AVG   4.02 mA    Max  28.6  mA
   1.25 <INDICATE transition> -> High
   2.03 [PPK2] 100k/s AVG   2.21 mA    Max  29.8  mA
   3.01 [PPK2] 100k/s AVG   0.002mA    Max   0.009mA
   4.02 [PPK2] 100k/s AVG   0.002mA    Max   0.008mA
   4.26 <WAKEUP>
   5.02 [PPK2] 100k/s AVG   1.11 mA    Max  24.5  mA
   5.60     [RX] Ready
   5.60 [TX] AT
   5.61     [RX] OK
   5.61 [TX] AT+CFUN=0
   5.77     [RX] OK
   5.77 [TX] AT%MDMEV=1
   5.78     [RX] OK
   5.78 [TX] AT%XPOFWARN=1,30
   5.80     [RX] OK
   5.80 [TX] AT%XTEMPHIGHLVL=60
   5.81     [RX] OK
   5.81 [TX] AT%HWVERSION
   5.81     [RX] %HWVERSION: nRF9160 SICA BQA
   5.81     [RX] OK
   5.81 [TX] AT%SHORTSWVER
   5.83     [RX] %SHORTSWVER: nrf9160_1.3.4
   5.83     [RX] OK
   5.83 [TX] AT#XSLMVER
   5.83     [RX] #XSLMVER: "2.3.0","2.3.1-8622ee1c632e"
   5.83     [RX] OK
   5.83 [TX] AT%XSYSTEMMODE=0,1,0,0
   5.85     [RX] OK
   5.85 [TX] AT%REL14FEAT=1,1,1,1,0
   5.86     [RX] OK
   5.86 [TX] AT%RAI=1
   5.86     [RX] OK
   5.87 [TX] AT%REDMOB=1
   5.88     [RX] OK
   5.88 [TX] AT%XDATAPRFL=0
   5.89     [RX] OK
   5.89 [TX] AT+CEPPI=1
   5.90     [RX] OK
   5.90 [TX] AT%XNETTIME=1
   5.91     [RX] OK
   5.91 [TX] AT+CNEC=24
   5.92     [RX] OK
   5.92 [TX] AT+CMEE=1
   5.93     [RX] OK
   5.93 [TX] AT%XSIM=1
   5.94     [RX] OK
   5.94 [TX] AT+CEREG=5
   5.95     [RX] OK
   5.95 [TX] AT+CSCON=1
   5.97     [RX] OK
   5.97 [TX] AT+CGEREP=1
   5.97     [RX] OK
   5.97 [TX] AT%XTIME=1
   5.99     [RX] OK
   5.99 [TX] AT%XMODEMSLEEP=1,500,10240
   6.00     [RX] OK
   6.00 [TX] AT+CPSMS=1,,,"00111000","00000000"
   6.00     [RX] %XMODEMSLEEP: 4
   6.00     [RX] OK
   6.01 [TX] AT%XBANDLOCK=1,"0000000000000000000000000000000000000000000000000000000000001000000010000000100010011010"
   6.02 [PPK2] 100k/s AVG   4.64 mA    Max  37.1  mA
   6.02     [RX] OK
   6.03 [TX] AT+COPS=1,2,"23003"
   6.05     [RX] OK
   6.05 [TX] AT+CGDCONT=1,"IP","hardwario.com"
   6.05     [RX] OK
   6.05 [TX] AT+CFUN=1
   6.10     [RX] OK
   6.11     [RX] %XMODEMSLEEP: 4,0
   7.01 [PPK2] 100k/s AVG  27.2  mA    Max  48.0  mA
   7.02     [RX] %XSIM: 1
   7.02 [TX] AT+CGSN
   7.02     [RX] 352656106109476
   7.02     [RX] OK
   7.02 [TX] AT+CIMI
   7.03     [RX] 901288000012723
   7.03     [RX] OK
   8.01 [PPK2] 100k/s AVG  35.5  mA    Max  65.8  mA
   9.00 [PPK2] 100k/s AVG  39.3  mA    Max  66.5  mA
  10.01 [PPK2] 100k/s AVG  19.2  mA    Max  62.9  mA
  11.02 [PPK2] 100k/s AVG   1.89 mA    Max   2.53 mA
  12.03 [PPK2] 100k/s AVG   1.89 mA    Max   2.50 mA
  13.01 [PPK2] 100k/s AVG   1.89 mA    Max   2.51 mA
  13.46     [RX] +CEREG: 2,"AE38","000AC51F",9
  14.01 [PPK2] 100k/s AVG   4.55 mA    Max  55.8  mA
  14.16     [RX] +CSCON: 1
  15.02 [PPK2] 100k/s AVG  33.2  mA    Max 290mA
  16.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  17.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  18.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  19.01 [PPK2] 100k/s AVG  33.1  mA    Max  47.8  mA
  20.01 [PPK2] 100k/s AVG  33.2  mA    Max  46.5  mA
  21.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  22.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  23.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  24.02 [PPK2] 100k/s AVG  33.3  mA    Max  46.1  mA
  24.43     [RX] +CGEV: ME PDN ACT 0,0
  24.43     [RX] +CNEC_ESM: 50,0
  24.43     [RX] %MDMEV: SEARCH STATUS 2
  24.44     [RX] +CEREG: 5,"AE38","000AC51F",9,,,"00000000","00111000"
  24.44 [TX] AT+COPS?
  24.45     [RX] +COPS: 1,2,"23003",9
  24.45     [RX] OK
  24.45 [TX] AT%XCBAND
  24.46     [RX] %XCBAND: 20
  24.46     [RX] OK
  24.46 [TX] AT+CEINFO?
  24.46     [RX] +CEINFO: 0,1,C,8,1,-87,18
  24.46     [RX] OK
  24.46 [TX] AT+CGDCONT?
  24.47     [RX] +CGDCONT: 0,"IP","hardwario.com","10.0.0.157",0,0
  24.48     [RX] +CGDCONT: 1,"IP","hardwario.com","",0,0
  24.48     [RX] OK
  24.48 [TX] AT#XDATACTRL=40
  24.48     [RX] %XTIME: ,"32305122655540",
  24.49     [RX] OK
  24.49 [TX] AT#XSOCKET=1,2,0
  24.49     [RX] #XSOCKET: 0,2,17
  24.50     [RX] OK
  24.50 [TX] AT%CONEVAL
  24.51     [RX] %CONEVAL: 0,1,7,54,24,42,"000AC51F","23003",493,6447,20,0,0,16,2,1,114
  24.51     [RX] OK
  25.00 [PPK2] 100k/s AVG  33.0  mA    Max 148mA
  25.65 [PPK2] ====== SUM: ATTACH   0.157uA/h during  25.6  s ======
  26.73 [TX] AT#XCONNECT="192.168.168.1",20000
  26.73     [RX] #XCONNECT: 1
  26.73     [RX] OK
  26.73 [TX] AT#XSOCKETOPT=1,50
  26.74     [RX] OK
  27.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  28.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  29.00 [PPK2] 100k/s AVG  33.4  mA    Max  46.3  mA
  30.01 [PPK2] 100k/s AVG  33.0  mA    Max  46.2  mA
  31.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  32.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  33.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  34.01 [PPK2] 100k/s AVG  33.5  mA    Max  46.4  mA
  35.02 [PPK2] 100k/s AVG  32.8  mA    Max  46.3  mA
  36.00 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  37.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  38.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  39.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.5  mA
  40.00 [PPK2] 100k/s AVG  32.6  mA    Max  46.0  mA
  41.01 [PPK2] 100k/s AVG  33.7  mA    Max  46.1  mA
  42.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  43.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.6  mA
  44.02 [PPK2] 100k/s AVG  33.7  mA    Max  48.2  mA
  45.02 [PPK2] 100k/s AVG  32.7  mA    Max  45.9  mA
  45.49     [RX] +CSCON: 0
  45.49     [RX] %XMODEMSLEEP: 1,86399999
  45.49 [TX] AT#XSLEEP=2
  45.49     [RX] OK
  46.00 [PPK2] 100k/s AVG  16.5  mA    Max 194mA
  47.02 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
  48.01 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
  49.03 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
  50.02 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
Parents
  • 0

    Maybe, it's easier to use SO_RAI_LAST and a own "empty message".

    At least in the past versions, the idea with SO_RAI_NO_DATA seems to be the same, sending a last empty message with NO_RESPONSE. Therefore you have to "connect" the udp socket in order to tell the stack, where to send this injected empty message.

    Just because you use a 90128 SIM:

    Do you know the HPPLMN search interval of your SIM card? Not that you get too surprised by some additional power consumption from that function (see HPPLMN search - reason unknown , it explains, why Nordic will always search for such a 9xxxx network.) By the way, did your modem ever report that 90128 network (see nRF9160 - who's device has seen/reports a network with a global PLMN starting with 9 ).

  • 0 in reply to Achim Kraus

    SO_RAI_LAST and an own "empty message" works as workaround.
    But SO_RAI_NO_DATA should still be fixed.

    As you can see from AT dialogue, UDP socket is "connected" (without any IP traffic).
    As you can see from modem trace, stack is not sending any empty message after SO_RAI_NO_DATA.

    HPPLMN search does not apply because Vodafone CZ uses 90128 for home NB IoT (all Vodafone CZ NB IoT SIMs are 90128 - i.e. "roaming"), so it is the highest priority PLMN already.

    Since SO_RAI_NO_DATA  and SO_RAI_ONE_RESP work reliably like a charm, I see no reason why SO_RAI_LAST should struggle with  HPPLMN search  or another corner strange causes. You can see from LTE RRC/NAS signaling (Modem Trace) that it is not the case also.

  • 0 in reply to Achim Kraus

    Hi,

    Achim Kraus said:
    Telekom 26201, NB-IoT, AS-RAI?, ONE-RESP => working

    In this case, R14 AS-RAI is not enabled but R13 CP-RAI is used.

    Achim Kraus said:
    Telekom 26201, NB-IoT, AS-RAI?, NO-DATA => not working

    UE is never asked from the network for the RAI support. Therefore, UE never signals to the network whether it supports AS-RAI or not. As a result, R14 AS-RAI is not enabled from the network to the UE.

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hi Dejan,

    all examples use the same application setup code.

    I don't see, how the application should know the extra info, which explains the result. But without that extra info it seems to be impossible to implement a working application. 

    26202, with AS-RAI

    4 days ago you wrote:

    > Modem supports AS RAI and that includes both SO_RAI_ONE_RESP and SO_RAI_NO_DATA.

    Now you write.

    > The issue here is that since R14 AS-RAI, SO_RAI_ONE_RESP + UDP transmission does not trigger signaling from UE to the network which could accelerate connection release. After receiving response, UE should use SO_RAI_NO_DATA socket option to the socket in order to tell the socket that there is no more data expected.

    In which case is a device able to use R14 AS-RAI with SO_RAI_ONE_RESP?

    If, in difference to your comment 4 days ago, R14 AS-RAI doesn't support SO_RAI_ONE_RESP, how does the application know, that the device didn't fallback and SO_RAI_ONE_RESP must not be used?

    26201, fallback to CP-RAI

    > UE is never asked from the network for the RAI support.

    The device uses the same setup as for ONE-RESP, which is working. Is SO_RAI_NO_DATA working with CP-RAI? If not, how does the application know, that the modem fallback to CP-RAI and the application must not use SO_RAI_NO_DATA?

  • 0 in reply to dejans

    Hi,

    Achim Kraus said:
    In which case is a device able to use R14 AS-RAI with SO_RAI_ONE_RESP?

    ONE_RESP + UDP does not deliver the expected result with R14 AS-RAI, since the R14 AS-RAI has no capability to signal such combination. With AS-RAI, the UE can only inform the network "more data expected". It is in R16 when 3GPP defines AS-RAI to be at the same expression level as CP-RAI.

    Achim Kraus said:
    If, in difference to your comment 4 days ago, R14 AS-RAI doesn't support SO_RAI_ONE_RESP, how does the application know, that the device didn't fallback and SO_RAI_ONE_RESP must not be used?

    Application has no way of finding this out. A safe way to use R14 AS-RAI so that the same code works with M1 and NB is to always issue setsockopt() with NO_DATA after receiving the reply UE is waiting for.

    Achim Kraus said:
    The device uses the same setup as for ONE-RESP, which is working. Is SO_RAI_NO_DATA working with CP-RAI? If not, how does the application know, that the modem fallback to CP-RAI and the application must not use SO_RAI_NO_DATA?

    CP-RAI is only available with NB-IOT. 
    If the UE does setsockopt() with ONE_RESP, sends data and after receiving a response from the network does setsockopt() with NO_DATA, the UE may trigger AS-RAI related BSR=0 signaling to the network (depending on whether the UE has uplink grant to do this or not). In this case, either CP-RAI or AS-RAI triggers the immediate release although the UE does not know which one of the two caused the release to happen.

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hi Dejans,

    using both ONE_RESP and NO_DATA looks more like a work-around and in my opinion requires explicit documentation.

    best regards

    Achim

  • 0 in reply to Achim Kraus

    Using both, SO_RAI_ONE_RESP and SO_RAI_NO_DATA , it works now with Rel 14 AS-RAI and the fallback to Rel 13 CP-RAI. Nice.

    I don't use the SO_RAI_LAST, but there I miss a event as "message sent", in order to use then the SO_RAI_NO_DATA.

    Is there a possibility to check, if a UDP message was actually sent?

Reply Children
  • 0 in reply to Achim Kraus

    Hi,

    If you use SO_RAI_NO_DATA with SO_RAI_ONE_RESP, you would not need to know when UDP packet has been sent.

    Best regards,
    Dejan

  • 0 in reply to Achim Kraus

    I am interested in that also, because there is not ANY signaling to the application, that send buffers are free to obtain another datagram. In case of bulk transfer through UDP, the application has to estimate the actual link transfer rate only based on lost datagrams. That is an extremely unfriendly technique for power saving. The application should be aware, whether the next datagram to be sent will or will not be dropped inside the device.

  • 0 in reply to Achim Kraus

    Hi,

    UDP is non-reliable protocol. Therefore, the information that UDP message left the modem would not guarantee anything or give any additional information. Typically, the assumption could be made that single UL UDP has left the modem when modem switches to RRC_IDLE.

    Best regards,
    Dejan

  • 0 in reply to dejans
    dejans said:
    UDP is non-reliable protocol. Therefore, the information that UDP message left the modem would not guarantee anything or give any additional information. Typically, the assumption could be made that single UL UDP has left the modem when modem switches to RRC_IDLE.

    Yes, UDP is non-reliable as any datagram, but available information for data transfer timings has to be passed to the application.
    Assumption can not be made on RRC_IDLE, because in such case link speed could not be utilized, i.e. such an approach wastes energy.

    For good energy management, it is essential to know whether packet dropping occurs/does not occur in the device, as this information is inherently available to the device.
    Another possibility is a statistical estimation, which needs to be based on the current line rate, which is known by the modem but not by the application, which needs to do the transmission timing, so the modem has to pass the information about the current line rate.

    How does the application know that the packet is not dropped in the modem?

    How does the application know what the current line rate is?

  • 0 in reply to dejans

    > UDP is non-reliable protocol. 

    UDP is the MOST reliable base for an upper protocol running over cellular modems using NB-IoT! The most serious upper protocols based on UDP do a much better job with NB-IoT and are much more reliable than TCP when running over NB-IoT.

    TCP handles "congestion control" and "message drops" internally, but that depends a lot on additional messages and the timings. The generally assumed times are far away from the times of NB-IoT and that causes then a lot of retransmissions. So the only thing you get reliable using TCP over NB-IoT is a lot more data ;-)

    > Typically, the assumption could be made that single UL UDP has left the modem when modem switches to RRC_IDLE.

    For a useful congestion control of the radio layer, the event, that a message is sent by the radio layer helps a lot. Other modems offer that.

    Using the RRC Idle event doesn't really help in that case. RRC IDLE is reached, if no more data is to be exchanged. That's either indicated by RAI (therefore all this discussion) or when the network's RRC Active Timer expires. It's not usable for the mentioned bulk transfer.

    I guess, if you ask the modem developers, there is a number of messages, which are queued and send one after the other. But the exact implementation is not documented. And for many applications it's better to have a feedback, how fast actually the messages are sent in order to do the queuing in a more specific way in the application. Maybe using POSIX poll with POLLOUT works, but AFAIK, that is missing in the documentation.

Related