Closed Bug 969305 Opened 11 years ago Closed 11 years ago

[LTE]According to protocol and roaming protocol of APN settings to make a data call.

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED DUPLICATE of bug 978709
tracking-b2g backlog

People

(Reporter: kchang, Assigned: jessica)

Details

When phone try to make a data call in LTE network, phone should know the values of the following 3 items, bearer data, protocol, and roaming protocol.
It is a 1.4+ bug.
blocking-b2g: --- → 1.4+
Jessica, you should consider this when you implement new apn types. Assign this bug to you. Thanks.
Assignee: nobody → jjong
There should be no problem with protocol and roaming protocol. Regarding to bearer data, from my understanding, it is used to match the radio technology; that is, apn is selected only if its bearer data matches the current radio technology. However, the selection of apn is done in gaia side for now. So, not sure how gecko is going to handle bearer data or no need to handle at all?
remove 1.4 flag as this is a feature work. let's use metabug (b2g-LTE-1.4) to keep tracking.
blocking-b2g: 1.4+ → backlog
Whiteboard: [FT:RIL]
Target Milestone: --- → 1.4 S3 (14mar)
(In reply to Jessica Jong [:jjong] [:jessica] from comment #3) > There should be no problem with protocol and roaming protocol. > Regarding to bearer data, from my understanding, it is used to match the > radio technology; that is, apn is selected only if its bearer data matches > the current radio technology. However, the selection of apn is done in gaia > side for now. So, not sure how gecko is going to handle bearer data or no > need to handle at all? You are right, we don't need to do it. Here is the feedback from partner. https://bugzilla.mozilla.org/show_bug.cgi?id=951764#c17
No longer blocks: 951764
According to comment 5, removing bearer from summary. And this bug isn't a blocker.
Summary: [LTE]According to bearer data, protocol, and roaming protocol of APN settings to make a data call. → [LTE]According to protocol and roaming protocol of APN settings to make a data call.
Target Milestone: 1.4 S3 (14mar) → ---
I'd like to understand comment #5 as I'll take care of the changes needed in the APN selection logic in the setting app. First of all as bearer data is a property of the APN it will be passed to the RIL plumbing. It's up to the RIL plumbing to use it or not. Second; I need to understand this: > > Regarding to bearer data, from my understanding, it is used to match the > > radio technology; that is, apn is selected only if its bearer data matches > > the current radio technology. Does the above means that the APN list to be shown in the setting app depends on the radio technology underneath?
Flags: needinfo?(jjong)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #7) > I'd like to understand comment #5 as I'll take care of the changes needed in > the APN selection logic in the setting app. First of all as bearer data is a > property of the APN it will be passed to the RIL plumbing. It's up to the > RIL plumbing to use it or not. Second; I need to understand this: Okay, I understand. > > > > Regarding to bearer data, from my understanding, it is used to match the > > > radio technology; that is, apn is selected only if its bearer data matches > > > the current radio technology. > > Does the above means that the APN list to be shown in the setting app > depends on the radio technology underneath? Yes, if there is a bearer data on in the apn setting, it is selected only if it matches the current radio technology, but I am not sure if it needs to be hidden in the UI if not matched. And from bug 951764 comment 17, it seems that we also need to consider radio technology change, e.g. from LTE to CDMA. You can use mozMobileConnections[x].data.type to check the current radio technology and refer to Android's design in [1] from line 2009. Thank you! [1] https://android.googlesource.com/platform/frameworks/opt/telephony/+/master/src/java/com/android/internal/telephony/dataconnection/DcTracker.java
Flags: needinfo?(jjong)
(In reply to Jessica Jong [:jjong] [:jessica] from comment #8) > (In reply to José Antonio Olivera Ortega [:jaoo] from comment #7) > > I'd like to understand comment #5 as I'll take care of the changes needed in > > the APN selection logic in the setting app. First of all as bearer data is a > > property of the APN it will be passed to the RIL plumbing. It's up to the > > RIL plumbing to use it or not. Second; I need to understand this: > > Okay, I understand. > > > > > > > Regarding to bearer data, from my understanding, it is used to match the > > > > radio technology; that is, apn is selected only if its bearer data matches > > > > the current radio technology. > > > > Does the above means that the APN list to be shown in the setting app > > depends on the radio technology underneath? > > Yes, if there is a bearer data on in the apn setting, it is selected only if > it matches the current radio technology, but I am not sure if it needs to be > hidden in the UI if not matched. And from bug 951764 comment 17, it seems > that we also need to consider radio technology change, e.g. from LTE to CDMA. > You can use mozMobileConnections[x].data.type to check the current radio > technology and refer to Android's design in [1] from line 2009. > > Thank you! > > [1] > https://android.googlesource.com/platform/frameworks/opt/telephony/+/master/ > src/java/com/android/internal/telephony/dataconnection/DcTracker.java Oh, and here is to match radio technology string to the integer in the apn database (use the array index): http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js#2604
(In reply to Jessica Jong [:jjong] [:jessica] from comment #8) > > Does the above means that the APN list to be shown in the setting app > > depends on the radio technology underneath? > > Yes, if there is a bearer data on in the apn setting, it is selected only if > it matches the current radio technology, but I am not sure if it needs to be > hidden in the UI if not matched. And from bug 951764 comment 17, it seems > that we also need to consider radio technology change, e.g. from LTE to CDMA. Thanks for the information. So It seems the APN list depends not only on current radio technology but also on radio technology changes.
Note that this is being handled in Bug 957917 attachment 8379454 [details] [diff] [review].
All patches are integrated in bug 978709.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Whiteboard: [FT:RIL]
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.