PSC (power saving commands in muxer mode) seems to be broken

[mdt@…]

the gsm.07.10 spec chapter 5.1.5.1 describes that the modem sends a PSC request
to indicate sleep. in case of wake up it sends another PSC request. i've never
seen any PSC request from the modem.

none the less the modem goes to sleep and does not allow sending packages
anymore. you have to wake up it in the way described in chapter 5.4.7 sending
flag-chars until the other end response with a flag-char. i never received any
such char from the modem.

just sending several flag-chars before any package wakes up the modem most of
the times but not always. in some cases the muxer runs into a timeout and the
modem can't be activated anymore.

i'm the author of gsm0710muxd and that's the area where i see this behavior.

[zecke@…]

Two things. Not waking up is bad, this is why Trolltech disabled the multiplexer
on their image (according to the comment in the code).

Regarding PSC and the Sleep Service I have some issue understanding the spec.

"The request primitive is used to advice the receiving device that the
transmitter wishes to enter a low
power state. The TS 0710 layer of the receiving unit sends an indication
primitive to the upper layer in order to inform
that the transmitting unit has entered the power saving state."

Who is the receiving device? From pure logic, the modem should be the receiving
device. There would be no sense if the modem is requesting us to sleep. The
sleep handling should be transparent to us. From what I remember and assume it
is right that you don't see the modem asking to go to a power saving state. It
is definately wrong that it is not answering when you are talking.

I do not know if you implement hardware flow control, but it would be
interesting to see what the modem is doing in regard to hardware flow control. I
have no idea if we have hardware flow control, I hope we do.

So IMO the only bug is that the AT engine is not waking up and giving a response.

[mdt@…]

i agree that the spec to me sounds very unspecific. but as i understand it the
PSC request are send from either side to indicate a start of power save. the
other side may then send queued buffers, inform other programs whatever. also
that side sets a flag to indicate that the other side is in power-save mode.

and if one side knows that the other side is in power save mode it has to send
these wake-up flags until the other side wakes up.

if the side in power-save mode wakes up by itself it sends a request to tell the
other side that it woke up. that side than may clear the flag mentioned above.

while this is all assumption and (for me, a non-native english interpreter of
the spec) not very clear i would assume i would see any PSC from the modem some
time.

so if there are no PSC requests at all and we assume that the modem is always in
a kind of power-saving (as if the flag mentioned above would be set all the
time) i have to send wakeups for each package. that's the current state of my
muxer. also ignoring that the modem does not answer as the spec describes would
be ignorable as long as it would always work.

[zecke@…]

GSM 07.10 is pretty clear in this respect (5.4.7):

"""
If either TE or MS wishes to enter a low-power state a power saving control
command message is sent to the other station on the multiplexer control channel.
The station receiving the message will complete the transmission of any
frames in progress, report a busy or power-down condition to higher layers,
freeze all timers and transmit the power saving control response message. When
the station that initiated the power saving control message receives the
acknowledgement it is then free to enter the reduced-power state.
"""

Yes, the modem would have to send something before going to (deep) sleep, it
doesn't, a violation to the spec. But honestly I think this is no big deal. I
don't remember seeing this on Wavecom (well they use their own multiplexer
format) and Siemens modules.

"""
Either station may send a power saving control command requesting that the other
station enters a low power state. The responding station must acknowledge this
command with a power saving control response message but need not obey the
command to enter a low-power state. If no response is received the commanding
station may repeat the command but must first use the wake-up procedure.
"""

This is the GSM stack on the host requesting the modem to sleep, I have seen a
variation of this on Siemens multiplexers. From a small chat with Sean Chiang
the modem is doing its own (deep) sleep, so sending this message is not
necessary (from what I understand). E.g. even if the modem would not respond to
these PSC, I think I wouldn't say there is much to fix. An obvious spec
violation but if we save power I think it is fine.

You should file a separate bug on the losing of frame and failing resync? From
what I have heard from Sean Chiang, the modem will drop/lose the first bytes
sent to the uart after a deep sleep, this is a hardware shortcoming. This means
the modem receives a frame without the sync/start flag/byte, which is by
definition invalid. The question is: Will it resync properly? Will it resync at
some point? I will try to do some tests myself, but please file a separate bug
on this issue. I think it is the only one to research and fix.

[mdt@…]

you did not quote the most important part:

"""
Either station may initiate a wake-up from the reduced power state by
the transmission of the wake-up signal which consists of continuous
flag characters. When the other station receives the flag characters
it will wake-up (if necessary) and start sending flag characters. When
the first station receives these flag characters it will stop sending
flags and start transmitting the first frame. When the second station
detects a valid frame it stops sending flags. The stations unfreeze
their timers and continue operation as before.
"""

i can easily ignore that there are not 'i want to sleep' event and send
the wakeup flag as described above. but can i be shure that the modem
actually woke up when i don't get a response as the spec describes?

and if the modem really drops one byte in the uart when sleeping i would
not care as long as it is one of those flag-chars i send. but some
negotiation that the modem really woke up is required i think.

btw: the timeout T3 for this procedure is 10sec which is a long time
when i.e. transmitting ppp packages...

[mickey@…]

I just added #1380, which may (or may not) be related.

[mickey@…]

I agree that there is a bug and I follow your analysis, Michael. Unfortunately,
this seems to be a limitation of the TI Calypso firmware and since this product
is end-of-life, we will not see a fix for it. Therefore, I'm closing this as
WONTFIX.