904514 - [meta] NetworkManager enhancement

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Edgar Chen [:edgar]]

Recently we had a discussion about the NetworkManager enhancement, file this bug as a meta bug to track status. Thanks

Please see below link for more detailed information.
* dev-b2g discussion: https://groups.google.com/d/msg/mozilla.dev.b2g/MVwLCASwFF8/X3hhGycCobcJ
* slides: http://people.mozilla.com/~echen/slides/NetworkManager_20130806/

Comment 1

[Ken Chang[:kenkai]]

Put this bug into backlog.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Attachment: [proposal] NetworkManager Enhancement 3.0

Please see Edgar’s original proposal for backgroud and details. Thank you, Edgar!
http://edgarchen.github.io/HTML_slides/NetworkManager_20140909/ 

In the slides above, we were to add some new APIs to nsIRadioInterface. However, after IPDL refactoringring and after moving sms out of RadioInterfaceLayer (v2.2),    nsIRadioInterfaceLayer and nsIRadioInterface become more mozilla internal usage. Thus, we do not want to add something back to nsIRadioInterface. 

We would instead create another specific interface for setupDataConnection(), deactitivateDataConnection, and  getDataConnectionList(). This attachment is to show the difference, while the main concept is totally the same as |NetworkManager_20140909|.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Anshul,
We'd like to make some progress on this topic in the first quarter. attachment 8552856 [details] displays the new architecture and introduces a proposal to CAF (page 9). Is it possible that your team could take a look and provide feedback by the end of this month? Do appreciate your help :)

Comment 5

[pgravel]

feedback provided through sync-up meeting.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to pgravel from comment #5)
> feedback provided through sync-up meeting.

Hi Phil,

Sorry in advance if I mix something up, but I couldn't remember that we talked about the feedback in the sync-up meeting last week. :( Would you minding commenting again directly on bugzilla? Thank you.

Comment 7

[Anshul]

Phil's analysis below:

- Who is responsible for managing reconnecting after network failure / data call drop?
- Who is responsible for managing retries of failed connection attempts?
- Network manager will need to manage the IMS data call the same was as the default data call.
- DSDS. Switching data calls between subscriptions is not trivial, and involves many special cases (i.e. MMS on sub 1 while data is active on sub 2). How will the RIL layer be notified that subscriptions need to be changed? 
- Will the NetworkManager/NetworkInterface layer be flexible enough for us to add additional NetworkInterface(s) for any special data call types?
- How are the nsIDataConnectionHandler “registered” with the NetworkInterface? In other words, how does the NetworkInterface actually know which nsIDataConnectionHandler object to use? (especially in the DSDS case).

Comment 8

[Jessica Jong [:jessica] (inactive)]

Attachment: FxOs DataConnection class diagram

(In reply to Anshul from comment #7)

Hi Phil, Anshul,

Attached is a class diagram of our plan. These modules are now in RadioInterfaceLayer.js, but will be moved to a separate module (see Bug 1114901), so that you can reuse them directly.

As you can see in the diagram, there is only one |gDataConnectionManager| that handles cross-sim/subscription requests. |gDataConnectionManager| manages a number of |DataConnectionHandler|s (one per sim/subscription). And each |DataConnectioHandler| manages different types of |RILNetworkInterface|s (e.g. default, mms, supl, etc.). |DataCall| represents an actual data connection and can be shared among |RILNetworkInterface|s.

We are going to add a new |nsIDataConnectionHandler| (name subject to change), which is the interface to send commands to the underlying RIL, so all you need to implement is this interface.

> Phil's analysis below:
> 
> - Who is responsible for managing reconnecting after network failure / data
> call drop?

Currently, |DataCall| itself handles the network failure / data call drop when it receives data call state changes.

> - Who is responsible for managing retries of failed connection attempts?

Same as above.

> - Network manager will need to manage the IMS data call the same was as the
> default data call.

Currently, IMS data call is treated as a secondary data call, that means there is no default route for this data type. We are not very sure how IMS data call should work, but we'd be happy to modify/implement it if we have more information about it.

> - DSDS. Switching data calls between subscriptions is not trivial, and
> involves many special cases (i.e. MMS on sub 1 while data is active on sub
> 2). How will the RIL layer be notified that subscriptions need to be
> changed? 

|gDataConnectionManager| handles the switch of subscriptions. In this case, we need to add one more function: |setDataRegistration(attach)| to |nsIDataConnectionHandler|, so |gDataConnectionManager| will set the unsubscription of one |nsIDataConnectionHandler| and the subscription of the other |nsIDataConnectionHandler|.
Gaia is in control of triggering the subscription switch command per user request.

> - Will the NetworkManager/NetworkInterface layer be flexible enough for us
> to add additional NetworkInterface(s) for any special data call types?

We think so. You just need to register the NetworkInterface to NetworkManager.
Other minor changes is to add the constant type in |nsINetworkManager.idl| and you might need to include the NetworkInterface type in function |isNetworkTypeSecondaryMobile()| in NetworkManager.js

> - How are the nsIDataConnectionHandler “registered” with the
> NetworkInterface? In other words, how does the NetworkInterface actually
> know which nsIDataConnectionHandler object to use? (especially in the DSDS
> case).

|nsIDataConnectionHandler| works just like the current |nsIRadioInterface|. So, each |RILNetworkInterface| can use its serviceId to get the corresponding |nsIDataConnectionHandler| instance. Please note that there will be one |nsIDataConnectionHandler| instance per sim/subscription.

---

Hope this answers your questions and please let us know if you have any other concerns.

Hsinyi, Edgar, please feel free to correct me or add any other comments. Thanks!

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Phil,
Does comment 8 resolve your concerns?

Comment 10

[pgravel]

Yes, thank you.

Comment 11

[BMO Automation]

Firefox OS is not being worked on