There was a discussion about the CDMA SMS handling and CDMA PDUs in the
IRC channel couple of days before. I would like to highlight the
differences between CDMA and GSM PDU and how we should proceed with this
from my understanding. Let me know your opinion.
Even though oFono supports +CMT and +CMTI, if we feed the incoming CDMA
PDUs to the SMS core it wont get decoded correctly, as there is
substantial differences between the GSM and CDMA SMS PDUs as described
in 3GPP2 specification C.S0015-B Short Message Service (SMS) for
Wideband Spread Spectrum Systems
For eg, the incoming PDU example that was mentioned in the IRC
+CMT: , 40,
40 - Length of the PDU in bytes
00 - Message Type ( 00 - SMS Point-to-Point)
00 - TeleService Identifier Tag (SMS Parameter Indentifier)
02 - TeleService Identifier Length (SMS Parameter Length)
10 - TeleService Identifier Value - First 8 bits
02 - TeleService Identifier Value - Second 8 bits
TeleService Identifier - 0x1002 - CDMA Messaging Teleservice
02 - Originating Address Tag
07 - Originating Address Length
02 - Originating Address 1st 8 Bits
8C - Originating Address 2nd 8 Bits
E9 - Originating Address 3rd 8 Bits
5D - Originating Address 4th 8 Bits
CC - Originating Address 5th 8 Bits
65 - Originating Address 6th 8 Bits
80 - Originating Address 7th 8 Bits
Digit Mode - 1 Bit
Number Mode - 1 Bit
Number Type - 0 or 3 bits
Number Plan - 0 or 4 bits
Number Fields - 8 Bits
Number Field occurrence of CHARi
CHARi - 4 or 8 bits ( 4 - in case of DTMF encoding, 8 - incase
of ASCII encoding)
Reserved - 0-7 bits
Lets take the 1st and 2nd 8 bits
02 - 0000 0010 ( Digit Mode bit - 0, Number Mode bit - 0)
8C - 1000 1100
As Digit mode bit is set to 0, Number Plan and Number Type is void
(0 bits) in this case.
So the remaining 6 bits of 1st 8bits and the first 2 bits of 2nd
8bit is Number fields
Number fields - 00 0010 10 - 0000 1010 - 0x0A (10 digits)
As Digit mode bit is set to 0, each address digit here is
represented as 4bit DTMF digit
0x8C 0xE9 0x5D 0xCC 0x65 0X80
1000 1100 1110 1001 0101 1101 1100 1100 0110 0101 1000 0000
10 0011 0011 1010 0101 0111 0111 0011 0001 1001 0110 0000 00
3 3 0 5 7 7 3 1 9 6 Last 6 bits
are reserved bits
Originating Address - 3305773196
06 - Bearer Reply Option Tag
01 - Bearer Reply Option Length
FC - First 6 bits Reply Sequence number and last 2 bits reserved set to
1111 1100 - 111111 REPLY_SEQ
08 - Bearer Data Tag
15 - Bearer Data Length
00 - Message Indentifier Tag ( Bearer Data Sub parameter )
03 - Message Indentifier Length
16 - Message Type 4 bits Message Id 4 Bits
8D - Message Id 8 Bits
30 - Message Id 4 Bits, UDH Header indicator 1 Bit, Reserved 3 Bits
How Message Identifier value 16 8D 30 was formed ?
Message type ( 4 bits ) - 1( 0001 - Deliver)
Message Identifier ( 16 bits ) - 26835( 0x68D3)
Header Indicator (1 bit) - 0 (UDH not present in User Data
Reserved ( 3bits) - 0 (000)
01 - User Data Tag ( Bearer Data Sub parameter )
06 - User Data Length
10 - Message Encoding 5 bits ( 0001 0000 ( 00010 = 2 -> 7-bit ASCII )) &
Number Fields 3 bits ( 000)
24 - Number Fields 5 Bits + User char field 1's 3 bits ( 0010 0100 )
18 - User char field 1's remaining 5 bits + User char field 2's 3 bits
30 - User char field 2's remaining 5 bits + User char field 3's 3 bits
60 - User char field 3's remaining 5 bits + User char field 4's 3 bits
80 - User char field 4's remaining 5 bits + Reserved 3 Bits (1000 0000)
Number Fields: 000 00100 - 04 (4 Character fields)
User Char  - 100 00011 - 0x83
User Char  - 000 00110 - 0x06
User Char  - 000 01100 - 0x0C
User Char  - 000 10000 - 0x10
Hex 0x83 0x06 0x0C 0x10
Octets 1000 0011 0000 0110 0000 1100 0001 0000
Septets 1000 001 10000 01 100000 1 1000001
Character A(0x41) A(0x41) A(0x41) A(0x41)
Message content: AAAA
Message Encoding - 2 (00010 - 5 bits)
Number Fields - 4 (0000 0100 - 8 bits)
User characters - 0x83 0x06 0x0C 0x10 ( 8 bits each)
00010 0000 0100 1000 0011 0000 0110 0000 1100 0001 0000
0001 0000 - 0x10
0010 0100 - 0x24
0001 1000 - 0x18
0011 0000 - 0x30
0110 0000 - 0x60
1000 0000 - 0x80 (Last 3 bits set to 0's(reserved bit) to complete
03 - Message Center Time Stamp Tag ( Bearer Data Sub parameter )
06 - Message Center Time Stamp Length
all date and time fields contain two 4-bit BCD numbers giving the
decimal value of the field.
10 - Year (2010)
10 - Month (10 - October)
04 - Day
04 - Hour
48 - Minutes
47 - Seconds
Time Stamp 04:48:47 04/10/2010
Message Type: Deliver (Incoming Message)
Message Identifier: 26835
Originating Address: 3305773196
Message content: AAAA
Message Center Time Stamp: 04:48:47 04/10/2010
As from the above decoding example we can see there is substantial
differences between the GSM and CDMA SMS specifications and so the SMS
atom needs many additions and needs to be heavily modified to support
also CDMA SMS handling. Currently the oFono sms file unit handles the
common and the GSM technology aspects of the SMS stack along with the
smsutils. The SMS atom has the GSM specific members, segmentation and
queuing logic. The smsutils mainly takes care of encoding/decoding of
the PDUs, which is GSM specific. As the segmentation and queuing logic
and the interface is common for both GSM and CDMA, we could reuse this
common code and add the CDMA handling into it and create a new
cdmasmsutils unit to support the CDMA SMS specifics, much like the
smsutils does already for GSM.
>> I found by looking in include/netreg.h that it should be up to the
>> plugin to
>> implement CSQ polling, however I can't find how it is supposed to be
>> Indeed, the plugin has no access to the netreg atom nor structure,
>> how is it
>> supposed to update one of these properties ?
> Drivers do not modify DBus properties directly. Instead you should
> be signaling the change to the core the regular way, via
> If you want to implement periodic signal strength reporting, then use
> g_idle_add_seconds to periodically send the +CSQ query. Please note
> that doing it this way you'd have to keep track of other states. For
> example, you might want to stop polling when the registration is
Oh, I see. Indeed, I noticed that signal strength reporting
is stopped when modem is not registered. I'll keep that in mind.
Thank you for the lead on this matter.
> Ideally you should be asking your vendor why the signal strength
> isn't reported properly.
Sure, it would be great to not have to do all these hacks to get it
working right !
TODO | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/TODO b/TODO
index 1fef651..3ddf363 100644
@@ -66,23 +66,6 @@ SIM / SIM File system
-- Add support for SIM 'ready' notifications from the driver to the core. Most
- modem manufacturers initialize the SIM (e.g. cache SIM file system, STK
- initialization, etc) internally before allowing the telephony stack to
- access these portions. When the PIN is locked, this can lead to oFono being
- too fast for the modem and asking it for things before the firmware is ready.
- The proposal is to introduce a new sim function:
- void ofono_sim_ready_notify(struct ofono_sim *sim);
- When oFono determines the SIM PIN is READY, it checks whether
- ofono_sim_ready_notify has been called. If it hasn't, then it stalls the
- initialization procedure (and calling post_sim) until
- ofono_sim_ready_notify is called.
- Priority: High
- Complexity: C2
- Support SIM authentication: SIM and AKA suites.
It seems my first post was lost, so here is a new try.
I am currently developing an ofono-based GSM control interface, using a
Hilo modem (I wrote the appropriate plugin) with the atmodem driver.
I am having trouble with signal strength reporting. The terminal does
signal strength by event. Hence, it is not possible to get the value
since Ofono expects it to be updated on a +CIEV event. I implemented a
new DBus method in the NetworkRegistration interface to force AT+CSQ
update the property value, but this is clearly not a valid solution.
I found by looking in include/netreg.h that it should be up to the
implement CSQ polling, however I can't find how it is supposed to be
Indeed, the plugin has no access to the netreg atom nor structure, so
how is it
supposed to update one of these properties ?
Thank you for your help.
These patches concern mmsd and update TODO and documentation to describe new
functionalities to add to mmsd.
Ronald Tessier (3):
TODO: Add new tasks
doc: Describe delivered group in storage doc
doc: Add new D-Bus methods to service interface
TODO | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++
doc/service-api.txt | 20 +++++++++++++++
doc/storage.txt | 30 ++++++++++++++++++++++
3 files changed, 117 insertions(+), 0 deletions(-)
Please find the changes in order to correct call forwarding states.
Changes from v4:
- Check the CFU in order to find whether querying is needed.
- End querying once CFU is active.
- Cache TYPE_ALL queries on supplementary services path.
Oleg Zhurakivskyy (5):
call-forwarding: Streamline number assignment
call-forwarding: Don't query cfs if CFU is active
call-forwarding: End querying once CFU is active
call-forwarding: Cache ss TYPE_ALL queries
TODO: Remove completed call forwarding state task
TODO | 17 -----------------
src/call-forwarding.c | 14 ++++++++------
2 files changed, 8 insertions(+), 23 deletions(-)
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
The first patch is fixes an obvious typo in the introspection.
The next three patches punch a whole through the DUN device
abstraction. If a Bluetooth device supports PAN and DUN at the same
time, there is no real good reason to offer both services to
user. ConnMan needs to figure out if a device supports both profile
(and then picking PAN). For this we need to provide an device
identifier. This API estension is modeled after the modem API, where
we have to do the same thing for HFP.
Daniel Wagner (4):
dundee: Fix signal name
dundee: Add Serial and Type documantation
dundee: Add Serial property
dundee: Add Type property
doc/dundee-api.txt | 12 ++++++++++++
dundee/bluetooth.c | 11 +++++++++++
dundee/device.c | 27 +++++++++++++++++++++++++++
dundee/dundee.h | 9 +++++++++
dundee/manager.c | 2 +-
5 files changed, 60 insertions(+), 1 deletion(-)
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
So here is the first oFono version for the "prefer pan over dun"
feature. Since this is a policy thing, it makes sense to place this
inside dundee and not inside ConnMan or BlueZ.
I am not really happy to pass in the UUIDs but I found it a lot nicer
than adding a 'filter' callback to struct bluetooth_profile.
Another idea how to implement it I had was, adding a blacklist when
registering the profile.
Let's start with the simplest possible solution.
Daniel Wagner (3):
bluetooth: Add list of UUIDs to probe function
bluetooth: Add PAN UUID
dundee: Ignore DUN device if PAN is present
dundee/bluetooth.c | 11 ++++++++++-
plugins/bluetooth.c | 8 +++++---
plugins/bluetooth.h | 3 ++-
plugins/hfp_hf.c | 2 +-
plugins/sap.c | 2 +-
5 files changed, 19 insertions(+), 7 deletions(-)
Some Huawei modems are trying to keep PPP session with the network alive even if the network is lost.
Thus oFono PPP session with the modem is never ended. Currently when network is lost, oFono will release the active contexts into the core however the context is still active at driver level. If the connection with the network is established again and we try to enable a data call, we have a crash.
This issue is very tricky there might be multiple solutions, here is one I discussed with Denis yesterday.
A new driver entry is added to release context into the driver in shutting down the PPP session between oFono and the modem.
Then ofono_context_deactivated() is called to signal the context is inactive at driver level.
In the case we lost the network and we are reattaching to the network but the PPP session had no time to be released, there is a mechanism to wait for the previous context to be released and then signal modem is reattached to the network. ConnMan can do again a data call.
Guillaume Zajac (3):
gprs-context: Add new driver entry
gprs-context: Add new driver entry definition
gprs: Release context in driver and core when network is lost
drivers/atmodem/gprs-context.c | 11 +++++
include/gprs-context.h | 2 +
src/gprs.c | 84 ++++++++++++++++++++++++++++++----------
3 files changed, 76 insertions(+), 21 deletions(-)