4 - Priority scale: High, Medium and Low
6 - Complexity scale: C1, C2, C4 and C8. The complexity scale is exponential,
7 with complexity 1 being the lowest complexity. Complexity is a function
8 of both task 'complexity' and task 'scope'.
10 The general rule of thumb is that a complexity 1 task should take 1-2 weeks
11 for a person very familiar with oFono codebase. Higher complexity tasks
12 require more time and have higher uncertainty.
14 Higher complexity tasks should be refined into several lower complexity tasks
15 once the task is better understood.
21 - Add support for Enhanced SMS (EMS) from 3GPP 23.040. These SMS messages
22 support a richer set of formatting elements, including bold/italic and
23 font size selection. Embedding images and sounds into the SMS is also
24 supported. This task should add support for receiving such SMS messages.
26 Proposed solution is to convert such messages to HTML and embed image /
27 sound data as embedded MIME in the generated HTML stream. The EMS messages
28 will have to be detected (by the presence of particular tags in the SMS)
29 and signaled separately from simple SMS messages.
34 - See / Cancel pending SMS messages over DBus. When oFono sends SMS messages
35 the method call is only returned when the message has been submitted to the
36 network. Instead we should return an object path and allow cancellation of
41 Owner: Yang Gu <yang.gu@intel.com>
43 - Persist outgoing SMS messages. Currently oFono persists incoming messages
44 that are fragmented. However oFono does not persist queued outgoing
45 messages. oFono should persist such messages and restore / requeue them
46 on the next oFono startup.
50 Owner: Kristen Carlson Accardi <kristen@linux.intel.com>
52 - Asynchronously acknowledge SMS DELIVER messages sent by the SMS driver
53 to core using ofono_sms_deliver_notify(). This may require the struct
54 ofono_sms_driver to be extended with one more function pointer like:
55 void (*deliver_ack)(unsigned char *pdu, int len, cb_t cb, void *data)
56 because currently messages are automatically acknowledged by either the
57 modem (this is the case of some AT modems) or the driver right after
58 ofono_sms_deliver_notify() and a failure to deliver at an upper level is
59 ignored. The PDU can be an RP-ACK or RP-ERROR message with optional
60 TP-User-Content element, for example if returned from USIM Data Download.
68 - SIM Call History plugin. New UICCs support four new SIM elementary files
69 for storing call history information on the SIM: EFici, EFict, EFoci, EFoct.
70 A plugin should be developed for oFono that will write to these files.
75 - Add support for SIM 'ready' notifications from the driver to the core. Most
76 modem manufacturers initialize the SIM (e.g. cache SIM file system, STK
77 initialization, etc) internally before allowing the telephony stack to
78 access these portions. When the PIN is locked, this can lead to oFono being
79 too fast for the modem and asking it for things before the firmware is ready.
81 The proposal is to introduce a new sim function:
82 void ofono_sim_ready_notify(struct ofono_sim *sim);
84 When oFono determines the SIM PIN is READY, it checks whether
85 ofono_sim_ready_notify has been called. If it hasn't, then it stalls the
86 initialization procedure (and calling post_sim) until
87 ofono_sim_ready_notify is called.
91 Owner: Pekka Pessi <pekka.pessi@nokia.com>
93 - Check SIM pin status if sim_change_pin fails. If it is anything other than
94 READY, we must tear the state back to pre_sim state and set the modem offline.
98 Owner: Marit Henriksen <marit.henriksen@stericsson.com>
100 - Add support for CPHS Customer Service Profile (CSP). This task adds support
101 for reading the EFcsp file and in particular, interpreting the PLMN mode bit
102 within the 'Value Added Services' service group.
104 Based on the PLMN mode value, manual network selection needs to either be
105 enabled or disabled in the netreg atom. Also to accommodate this, there
106 probably needs to be a new 'forced' mode to indicate that manual network
107 selection is disabled.
111 Owner: Aki Niemi <aki.niemi@nokia.com>
113 - Support SIM authentication: SIM and AKA suites.
117 Owner: Pekka Pessi <pekka.pessi@nokia.com>
119 - Support SIM authentication: GBA_U suite.
126 ISIM is the SIM application for IP Multimedia Subsystem, specified in
127 3GPP TS 31.103. The UICCs can support multiple ISIMs for different IMS
137 - Support HFP AG emulator. We should provide a new HFP_AG_EMULATOR atom type
138 that will implement the Bluetooth HFP AG profile. Voicecall atom, netreg
139 atoms can register command handlers for this atom appropriately.
143 Owner: Frédéric Danis <frederic.danis@linux.intel.com>
145 - Support extensions to HFP AG emulator. Some carkits support additional
146 AT command extensions to the Bluetooth HFP AG standard. Refer to CE4A
147 white paper: "AT-commands for Automotive Premium Phone Integration".
148 Plugins can register additional command handlers appropriately to handle
153 Depends: HFP AG emulator
154 Owner: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
156 - Support HSP AG. Similar to HFP AG emulator but implements the much reduced
157 Bluetooth HSP AG profile.
162 - Support DUN emulator. Implement the Bluetooth DUN profile with only mandatory
163 AT command support. Implement USB DUN as well.
167 Owner: Gustavo F Padovan <padovan@profusion.mobi>
169 Depends: PPP Server mode
171 - Support Bluetooth SPP profile.
180 - Flight Mode support. Add an 'Online' property to the Modem interface that
181 will control the online state of the modem. When Online state is True all
182 atoms are available. When Online state is False, all network related items
183 are removed (e.g. CallSettings) or enter into reduced functionality set
184 where only the SIM is available (e.g. DataConnectionManager, SimManager, etc)
188 Owner: Pekka Pessi <pekka.pessi@nokia.com>
194 - PPP Server support. Extend GAtPPP to support PPP Server role, similarly to
195 how existing GSM modems support PPP GPRS contexts.
200 - IPv6 CP support. To support IPv6 based GPRS contexts via PPP, GAtPPP
201 needs to be updated to support IPv6CP from RFC 2472.
206 - Add support for IPv6 GPRS contexts.
210 Owner: Mika Liljeberg <mika.liljeberg@nokia.com>
216 - Neighbor Cell Info. Add dedicated atom, D-Bus API and atom driver(s) for
217 Neighbor Cell information.
219 This feature is not discussed in 27.007, thus manufacturer specific commands
224 Owner: Antti Paila <antti.paila@nokia.com>
227 Supplementary Services
228 ======================
230 - Closed User Group (CUG) support.
235 - Call Completion to Busy Subscriber (CCBS) support
237 This feature is not discussed in 27.007, thus manufacturer specific commands
243 - User to User Signaling (UUS) support
248 - Multiple Subscriber Profile (MSP) support
253 - CPHS Support. This includes ALS and CPHS specific elementary files.
262 - Supplementary service notifications on remote party actions:
263 - call has been put on hold (+CSSU: 2)
264 - call has been retrieved (+CSSU: 3), and
265 - joining call to a multiparty conference (+CSSU: 4)
269 Owner: Pekka Pessi <pekka.pessi@nokia.com>
271 - Long phone numbers. According to 3GPP TS 24.008, the callee address
272 can be up to 80 digits long.
276 Owner: Rafael Ignacio Zurita <rafael.zurita@profusion.mobi>
278 - Dial strings. Include CLIR prefixes and 2nd stage dial strings in the
279 DialString call property. Add dialstring accessor method to C API.
284 - Provide feedback of sent DTMF tones. Emit SendingTones signal if modem can
285 provide approximate starting and stopping times for DTMF tones. Signal
286 argument contains a string of DTMF tones to be sent, or empty string when
287 all tones has been sent.
291 Owner: Pekka Pessi <pekka.pessi@nokia.com>
293 - Blacklisting. According to 3GPP TS 22.001 annex E, the TE must provide
294 automatic calling repeat call attempt restrictions.
296 There should be a method to manually reset blacklisting.
305 - Support Refresh proactive command. The specification defines 7 types
308 - NAA File Change Notification
309 - NAA Initialization and File Change Notification
310 - NAA Initialization and Full File Change Notification
312 - NAA Application Reset (2G only)
313 - NAA Session Reset (3G only)
315 The 'NAA Initialization' type will be ignored by oFono, it is assumed
316 this is handled by the modem.
318 For 'UICC Reset', 'NAA Application Reset' and 'NAA Session Reset' oFono
319 will first check whether there are any calls or ussd operations active.
320 If there are, the appropriate response will be sent (e.g. busy on call
321 or screen busy terminal response.) Otherwise a positive response will be
322 sent to the driver. In the case of a 'UICC Reset' the driver / modem
323 can interpret this that it is safe to reset the UICC.
325 Alternatively, the driver / modem can notify the core of the SIM removal
326 / SIM insertion events without using the Refresh proactive command. It
327 is up to the driver / modem to perform a warm reset. In particular, 3GPP
328 31.111 mandates that any change to EFimsi is done by using 'UICC Reset',
329 'NAA Application Reset' or 'NAA Session Reset'. Please see 3GPP 31.111
332 Other types will be handled by oFono flushing the EF cache of the files
333 affected (or the entire SIM cache in case of Full File Change Notifications)
334 and re-reading the affected files. Any properties derived from these
335 Elementary Files will be updated and signaled using PropertyChanged.
344 - Modem Emergency mode. Support network registration and online/offline
345 mode during the emergency calls and related network activity (e.g.,
346 network-initiated location request via supplementary service channel).
348 Proposed solution is to introduce a new Emergency boolean property to the
349 Modem D-Bus interface and new functions to modem interface:
351 - ofono_modem_emergency_mode_inc()
352 - ofono_modem_emergency_mode_dec()
353 - ofono_modem_emergency_mode_get()
354 - ofono_modem_add_emergency_mode_watch()
355 - ofono_modem_remove_emergency_mode_watch()
357 When emergency mode is requested, modem is set to online (if needed) and
358 the watchers are notified. There can be multiple parties requesting
359 emergency mode. When all of them have completed the emergency-related
360 operation and called ofono_modem_emergency_mode_dec(), modem is set to
361 offline (if needed) and the watchers are again notified.
366 - Country / Operator specific emergency numbers. Figure out how to support
367 countries / operators with specific mandated emergency numbers which are
368 not part of the standard emergency number list. This needs to be queried
369 by the voicecall atom every time a new SIM is inserted. The list is
370 assumed to be managed by the modem. If no such functionality is available,
371 then the 3GPP mandated behavior is used.
376 - Network updating the emergency number list. Support the list of emergency
377 numbers dynamically updated by the network.
381 Owner: Petteri Tikander <petteri.tikander@ixonos.com>
387 - Bluetooth SAP Client support. The Telit UC864-G devices support Bluetooth
388 SAP client mode. This requires the use of a modem side-channel to read the
389 APDU & CPDU data and send it to the remote phone device over Bluetooth RFCOMM
395 - PolicyKit support. Add support for PolicyKit checking of all oFono D-Bus
401 - Internet Access Provider database. Have oFono automatically configure
402 GPRS contexts based on an internal database. Database format to be decided.
403 If there are multiple matches in the database, then some user intervention
408 Owner: Jukka Saunamäki <jukka.saunamaki@nokia.com>
410 - Add support for GPS power control atom. Many modem manufacturers provide
411 a GPS unit with their modem hardware. This unit can be turned on or off
412 and frequently takes over one of the tty ports that the modem provides.
414 This feature is not discussed in 27.007, thus manufacturer specific commands
419 Owner: Rafael Ignacio Zurita <rafael.zurita@profusion.mobi>
421 - Add Location Service API for providing basic E911 support.
422 This will be based on the 27.007 defined AT commands using
423 XML for transport of positioning request and responses.
427 Owner: Sjur Brændeland <sjur.brandeland@stericsson.com>
429 - Add support for main.conf. This task will add support for general
430 as well as per-atom configuration options that are read and parsed
431 at startup from a configuration file under /etc/ofono.
435 Owner: Aki Niemi <aki.niemi@nokia.com>
440 - Add support for Mobile Originated and Mobile Terminated Voice Call over
441 a CDMA network. This includes management of call state and providing
442 appropriate values for the LineIdentification in each case.
446 Owner: Dara Spieker-Doyle <dara.spieker-doyle@nokia.com>
448 - Add support for Three-Way Calling over a CDMA network. Three-Way Calling
449 provides the subscriber with the capability to add a third party to an
450 established two-party call, so that all three parties may communicate in a
453 In CDMA mode, the originating subscriber of a current conversation can
454 request for a third party to be added to a conversation by sending a Flash
455 With Information Message (FWIM) with dialed digits to the network. Upon
456 setting up a two-way conversation with the added party, the originating
457 subscriber can request to establish a three-way conversation by sending
458 another Flash With Information Message. Upon receiving the second Flash With
459 Information Message, the MSC reconnects the original party to the
460 conversation thus completing the setup of a three-way conversation.
462 CDMA Three-Way Calling is described by Figure B-5 in 3GPP2 C.S0005-E Version
468 - Add support for Call Waiting over a CDMA network. Call Waiting (CW) provides
469 notification of an incoming call to an originating subscriber, while the
470 subscriber's call is in the 2-way state. Subsequently, the originating
471 subscriber can either answer or ignore the incoming call. If the originating
472 subscriber answers the second call, it may alternate between the two calls.
474 In CDMA mode, the originating subscriber of a current conversation will
475 receive either a Flash With Information Message or an Alert With Information
476 Message from the network if there is an additional mobile terminated voice
477 call incoming. The originating subscriber can change conversation parties by
478 sending a Flash With Information Message to the network and the MSC will
479 toggle the speech path between the two conversations.
481 CDMA Call Waiting is described by Figure B-6 in 3GPP2 C.S0005-E Version
487 - Support sending DTMF tones over CDMA network.
492 - Support optional network-based Plus Code Dialing for international calls over
493 a CDMA network. An input key, e.g. the "+" key, or a functional equivalent
494 can be used to replace the international access prefix when dialing. When
495 received, transmitted or stored, an international indicator can be included
496 with the address digits although it is the responsibility of the network to
497 ignore the international indicator when attached to a national number. This
498 is described in Section 2.7.1.3.2.4 of 3GPP2 C.S0005-E v2.0 and Section 1.2
499 of 3GPP2 N.S0027 v1.0.
507 - Support CDMA SMS stack in PDU mode. This includes basic support of
508 SMS Point-to-Point Message, SMS Broadcast Message and SMS Acknowledge
509 Message as per 3GPP2 C.S0015-B version 2.0.
514 - Support sending Wireless Messaging Teleservice (WMT) Submit Message and
515 receiving WMT Deliver Message as defined 3GPP2 C.S0015-B version 2.0.
520 - Support Delivery Acknowledgment. oFono allows requesting of CDMA SMS
521 Delivery Acknowledgment via the MessageManager's
522 UseDeliveryAcknowledgement property. If enabled, oFono's CDMA SMS stack
523 will encode the Reply Option subparameter in the Submit message and
524 process incoming SMS Delivery Acknowledgment Message. oFono will notify
525 UI either via DBus or history plugin API.
530 - Support receiving Voice Mail Notification (VMN) Teleservice Deliver
531 message. CDMA network uses VMN Teleservice to deliver the number of
532 messages stored at the Voice Mail System to the CDMA mobile subscriber.
537 - Support sending Wireless Enhanced Messaging Teleservice (WEMT) Submit
538 Message and receiving WEMT Deliver Messsage as defined 3GPP2 C.S0015-B
541 WMT does not support message fragmentation thus can not be used to for
542 long message. WEMT is devised to support long message and Enhanced
543 Messaging Service (EMS). The WEMT SMS message's CHARi field of the
544 subparameter User Data encapsulate GSM-SMS TP-User Data as defined in
545 Section 9.2.3.24 of 3GPP TS 23.040.
550 - Support sending Wireless Application Protocol (WAP) Teleservice Submit
551 Message and receiving WAP Deliver Messsage as defined 3GPP2 C.S0015-B
557 - Support Call-Back Number. The Call-Back Number subparameter indicates
558 the number to be dialed in reply to a received SMS message.
560 In transmit direction, oFono allows setting of Call-Back Number. If the
561 Call Back Number property is set, CDMA SMS stack will encode Call-Back
562 Number subparameter in the Submit Message.
564 In receiving direction, oFono will process the Call-Back Number
565 subparameter in the incoming Deliver Message and notify UI of the
566 Call-Back Number together with the newly received text message.
571 - Support immediately displayed message. oFono CDMA SMS stack will
572 process the optional Message Display Mode subparameter in the incoming
573 SMS message. If Message Display Mode subparameter indicates the
574 message display mode is Immediate Display, oFono will send
575 ImmediateMessage signal, otherwise oFono will send IncomingMessage
585 - Support Commercial Mobile Alert Service (CMAS) over CDMA systems. CMAS
586 over CDMA system is defined in TIA-1149. The CMAS message is carried in
587 the CHARi field of the User Data subparameter of CDMA SMS Broadcast
593 CDMA NETWORK ACQUISITION
594 ========================
596 - Support reporting of the received signal strength indicator (RSSI)
597 measurement and of the pilot energy ratio (Ec/Io) measurement, for the
598 currently acquired CDMA network.
602 Owner: Dara Spieker-Doyle <dara.spieker-doyle@nokia.com>
604 - Support reporting of the received signal strength indicator (RSSI)
605 measurement and of the signal to interference-plus-noise ratio (SINR)
606 measurement, for the currently acquired 1xEV-DO data network.
611 - Support reporting of the Enhanced Roaming Indicators (ERI) to indicate the
612 current roaming condition of the CDMA mobile device. Each indicator maps to
613 a unique display number within the Standard and Non-Standard service ranges,
614 as described in Section 8 of 3GPP2 C.R1001-C v1.0.
615 These numbers are stored on the device in the (Enhanced) Preferred Roaming
616 List (PRL) and it is the responsibility of the modem to broadcast the
617 relevant indicator for a currently acquired system. Further details of the
618 system acquisition process are described in 3GPP2 C.S0016-B v1.0.
623 - Support reporting of identifiers of the currently acquired CDMA network,
624 including the System Identifier (SID) and the Network Identifier (NID),
625 It is the responsibility of the modem to broadcast the relevant identifiers
626 for a currently acquired system, and these identifiers are provided by the
627 network. This is described in 3GPP2 C.S0005-E v2.0.
632 - Support International Roaming, including support for reporting the Mobile
633 Country Code (MCC) and the Mobile Network Code (MNC) for the currently
634 acquired network. International Roaming is provided via enhancements to the
635 PRL by encoding the MCC and the (two digit only) MNC in existing SID/NID
636 fields, as described in the CDMA Development Group standards Document "IPRL
637 Enhancements for International Roaming - CDG Doc #86". It is the
638 responsibility of the modem to broadcast the values for the currently