Re: GPRS support for Ofono
Hi Remi, > >> > there has to be a mapping on some level. At least one driver has to do > >> > some sort of mapping. If you have a better idea to handle it in the > >> > core daemon, please propose something. > >> > >> Of course we have context ID. But we cannot manage them ourselves - the > >> modem does it. > > > > I did understand that part. What is your proposal to handle this better? > > > > Problem is I don't know how the PDP context setup flow works in ISI and > > so I would be wild guessing until you propose something. > > It goes like this: > > 1. Allocate context ID from the modem. > 2. Configure context. > 3. Authenticate. > 4. Setup local link. > 5. Activate context. > 6. Profit. > 7. Deactivate context. > 8. Tear down local link. > 9. Delete context ID. doesn't sound like a big problem to me at all. I think there are multiple ways to solve this and make it simple for all drivers to provide their own method of allocating context IDs. One approach might be to add a callback to ofono_grps_context_driver to allocate the context ID. If present then the modem driver is responsible to allocate them. If not then the core will do it for you. Essentially a way of overwriting gprs_cid_alloc() from within a driver. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hello, On Thu, 10 Dec 2009 15:45:21 +0100, Marcel Holtmann wrote: >> > there has to be a mapping on some level. At least one driver has to do >> > some sort of mapping. If you have a better idea to handle it in the >> > core daemon, please propose something. >> >> Of course we have context ID. But we cannot manage them ourselves - the >> modem does it. > > I did understand that part. What is your proposal to handle this better? > > Problem is I don't know how the PDP context setup flow works in ISI and > so I would be wild guessing until you propose something. It goes like this: 1. Allocate context ID from the modem. 2. Configure context. 3. Authenticate. 4. Setup local link. 5. Activate context. 6. Profit. 7. Deactivate context. 8. Tear down local link. 9. Delete context ID. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > On Thu, 10 Dec 2009 15:27:26 +0100, Marcel Holtmann > > wrote: > > there has to be a mapping on some level. At least one driver has to do > > some sort of mapping. If you have a better idea to handle it in the core > > daemon, please propose something. > > Of course we have context ID. But we cannot manage them ourselves - the > modem does it. A context atom in ofono represents the active/activating context. The id is managed by the core since the majority of the hardware in this world does it like this. There can be several gprs-context atoms present in a modem at once. So context management inside the gprs context would be extremely tricky. I suggest you store the id in a private struct and let the modem pick you one. As long as you notify oFono of context deactivation using the id it gave you, everyone is happy. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > there has to be a mapping on some level. At least one driver has to do > > some sort of mapping. If you have a better idea to handle it in the core > > daemon, please propose something. > > Of course we have context ID. But we cannot manage them ourselves - the > modem does it. I did understand that part. What is your proposal to handle this better? Problem is I don't know how the PDP context setup flow works in ISI and so I would be wild guessing until you propose something. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Thu, 10 Dec 2009 15:27:26 +0100, Marcel Holtmann wrote: > there has to be a mapping on some level. At least one driver has to do > some sort of mapping. If you have a better idea to handle it in the core > daemon, please propose something. Of course we have context ID. But we cannot manage them ourselves - the modem does it. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > I haven't had time to look at the context stuff yet. > > It's just worse. oFono is enforcing an integer ID on any primary context. > This is again an idiosyncrasy of AT commands. With ISI modems, the context > ID space is managed by the modem, so oFono does not get to choose. > > In theory, I could remap those, but that really would not make sense. there has to be a mapping on some level. At least one driver has to do some sort of mapping. If you have a better idea to handle it in the core daemon, please propose something. Please remember that non of us have the ISI specification and until you guys communicate these details with us, we go based on what public specifications are using. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Wed, 09 Dec 2009 13:38:18 +0100, Rémi Denis-Courmont wrote: > I haven't had time to look at the context stuff yet. It's just worse. oFono is enforcing an integer ID on any primary context. This is again an idiosyncrasy of AT commands. With ISI modems, the context ID space is managed by the modem, so oFono does not get to choose. In theory, I could remap those, but that really would not make sense. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi > > I have two suggestions here: > > 1. Lets make it work first, we can then make it work better. > > 2. Can you describe these optimizations and suggest how the API/behavior can > > be changed to take advantage of them? > > We just need to know if the core or the upper-layer application intends to > activate a context. It is a boolean flag hint to Attach basically. I really prefer that we get this working first and then talk again about usefulness, API issues etc. We are clearly stating that the API is not set in stone yet. And that is on purpose since we still have some areas where we have to see what makes most sense in practice and how it plays together with other systems. In some cases we better add a configuration option to a global config file instead of exposing this via a D-Bus. In other cases D-Bus is the better choice. For me the attach policy sounds like a configuration option that the system integrators should be choosing at package time depending on operator preference/requirement. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > - Message d'origine - > > > Again, I don't see a point of exposing this to the user. Worst case we > > can always add intelligence / heuristics to oFono to attempt re-attaching > > periodically. We have to solve this for all modems, since there are no > > such 'auto-attach' semantics in 27.007. > > If it comes to the question of usefulness, I find the current attach/detach > to be even more useless than always-attach/demand-attach. There are actually usecases for being attached and not having an active context. Most of this comes from weird devices that cannot be attached to GSM & GPRS at the same time or have other limitations. We also have MO SMS bearer selection (+CGSMS) to consider here. Not to mention that the network can actually activate a context on the modem without user action which is used in IMS I believe. And of course context activation latency is also something to consider. Please don't just say 'It sucks' or 'I don't like this', offer up what *you* think the API should look like. The most appropriate time was in September when we were having these design discussions, but it is never too late to change it. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
- Message d'origine - > Again, I don't see a point of exposing this to the user. Worst case we can > always add intelligence / heuristics to oFono to attempt re-attaching > periodically. We have to solve this for all modems, since there are no such > 'auto-attach' semantics in 27.007. If it comes to the question of usefulness, I find the current attach/detach to be even more useless than always-attach/demand-attach. AT modems will attach automatically when a context is activated, so do ISI modems (when adequately configured), and foobar modems could always emulate it (from inside their context API). I agree that auto-attach is not of much use to end-users, for the exact same reason that attach is not very useful. But it is apparently of use to network operators at least. > One strategy you can use today is to just activate auto-attach when the driver > is asked to attach and force a detach when the driver is asked to detach. > This is essentially the behavior of most AT command modems. Sure. ISI modems can do that too. And I argue it makes manual attach/detach even more useless than auto-attach. I'd note that flight mode requires deregistering from the network as a whole, not just detaching from GPRS anyway. So I can implement the current attach/detach logic, but it seems not very pertinent to me as an API. > I have two suggestions here: > 1. Lets make it work first, we can then make it work better. > 2. Can you describe these optimizations and suggest how the API/behavior can > be changed to take advantage of them? We just need to know if the core or the upper-layer application intends to activate a context. It is a boolean flag hint to Attach basically. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > The core only reports these attributes, it doesn't actually use them for > > anything. When attached you can simply send a status=registered, LAC, > > CellId and Tech set to -1. We can see about removing these a bit later. > > I would do that, but there is no apparent way to return the attached state > without making a statement on roaming as well. IOW, this is unimplementable > with ISI. Don't worry about this for now. The roaming of CGREG is never checked, only CREG roaming state is checked. You can safely return status=registered here. > > > > That is different. If you are outside of coverage, or in a non-GPRS > > > area, you can turn auto-attach on. That will make some operators happy > > > but it wont't attach just yet. > > > > Sorry I don't see a practical difference. You set 'Powered' to TRUE, > > gprs atom issues a 'set_attached' with TRUE. Once you have attached the > > driver sends out a ofono_gprs_status_notify. Whether this happens in 1 > > second or 2 hours doesn't really matter. > > Again and again, auto-attach and attach are different things. Setting > attach to false will forcefully deactivate all existing contexts and detach > the terminal from GPRS. Setting auto-attach to false will cause the > terminal to detach after all pending contexts are deactivated, but won't > cause them to be detached immediately (AT+CGATT does that). > > Conversely, enabling auto-attach will cause the terminal to attach once it > has GPRS coverage, whereas false will have it wait for an explicit attach > request, or implicitly for a context activation. This is dkifferent from > attaching which is an immediate action and will fail if GPRS is unavailable > (like AT+CGATT). > Again, I don't see a point of exposing this to the user. Worst case we can always add intelligence / heuristics to oFono to attempt re-attaching periodically. We have to solve this for all modems, since there are no such 'auto-attach' semantics in 27.007. One strategy you can use today is to just activate auto-attach when the driver is asked to attach and force a detach when the driver is asked to detach. This is essentially the behavior of most AT command modems. > Furthermore, when attaching, the terminal is supposed to state its intent > to activate a context immediately or not. If it does, then some > optimizations are possible in 3G case. I have two suggestions here: 1. Lets make it work first, we can then make it work better. 2. Can you describe these optimizations and suggest how the API/behavior can be changed to take advantage of them? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
> The core only reports these attributes, it doesn't actually use them for > anything. When attached you can simply send a status=registered, LAC, CellId > and Tech set to -1. We can see about removing these a bit later. I would do that, but there is no apparent way to return the attached state without making a statement on roaming as well. IOW, this is unimplementable with ISI. > > That is different. If you are outside of coverage, or in a non-GPRS area, > > you can turn auto-attach on. That will make some operators happy but it > > wont't attach just yet. > > Sorry I don't see a practical difference. You set 'Powered' to TRUE, gprs > atom > issues a 'set_attached' with TRUE. Once you have attached the driver sends > out a ofono_gprs_status_notify. Whether this happens in 1 second or 2 hours > doesn't really matter. Again and again, auto-attach and attach are different things. Setting attach to false will forcefully deactivate all existing contexts and detach the terminal from GPRS. Setting auto-attach to false will cause the terminal to detach after all pending contexts are deactivated, but won't cause them to be detached immediately (AT+CGATT does that). Conversely, enabling auto-attach will cause the terminal to attach once it has GPRS coverage, whereas false will have it wait for an explicit attach request, or implicitly for a context activation. This is dkifferent from attaching which is an immediate action and will fail if GPRS is unavailable (like AT+CGATT). Furthermore, when attaching, the terminal is supposed to state its intent to activate a context immediately or not. If it does, then some optimizations are possible in 3G case. Rémi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > - Message d'origine - > > > I already told you I'm open to fixing it. However 27.007 is the only > > standard we have right now. > > That's easy to fix. Remove those from the GPRS status. The core only reports these attributes, it doesn't actually use them for anything. When attached you can simply send a status=registered, LAC, CellId and Tech set to -1. We can see about removing these a bit later. > > > Different network probably not, but different base station? Again I'm > > not the expert here either. The API was posted for review back in early > > September, and Nokia participated in the design. > > That is not possible either to our understanding. If it were possible, the > ISI modems would expose that data separately, which they don't. I suspect you're right. > > I believe the current API already covers this. Context active state and > > attached state are tracked separately. Thus you can be attached with no > > active context, I do it all the time. Can't you just turn on your 'auto- > > attach' mode when oFono calls 'set_attached' with TRUE and turn off > > attachment when oFono calls 'set_attached' with FALSE? > > That is different. If you are outside of coverage, or in a non-GPRS area, > you can turn auto-attach on. That will make some operators happy but it > wont't attach just yet. Sorry I don't see a practical difference. You set 'Powered' to TRUE, gprs atom issues a 'set_attached' with TRUE. Once you have attached the driver sends out a ofono_gprs_status_notify. Whether this happens in 1 second or 2 hours doesn't really matter. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
- Message d'origine - > I already told you I'm open to fixing it. However 27.007 is the only standard > we have right now. That's easy to fix. Remove those from the GPRS status. > Different network probably not, but different base station? Again I'm not the > expert here either. The API was posted for review back in early September, > and Nokia participated in the design. That is not possible either to our understanding. If it were possible, the ISI modems would expose that data separately, which they don't. > > No no, I am not talking about network-initiated context *activation*. I am > > talking about the requirement from some operator that the device be always > > *attached* even if it has no active contexts. Note that the battery impact > > is negligible. Also, this is NOT quite the same as attaching when oFono > > starts: the device could be outside of the GPRS network; auto-attach will > > get it attached as soon as possible. > > I believe the current API already covers this. Context active state and > attached state are tracked separately. Thus you can be attached with no > active context, I do it all the time. Can't you just turn on your 'auto- > attach' mode when oFono calls 'set_attached' with TRUE and turn off attachment > when oFono calls 'set_attached' with FALSE? That is different. If you are outside of coverage, or in a non-GPRS area, you can turn auto-attach on. That will make some operators happy but it wont't attach just yet. Whether it makes practical sense, I dunno. Operators ask for this. Maybe there is a reason (maybe not). Rémi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Rem, > > That is because 3GPP in their infinite wisdom structured the spec this > > way. > > Just because AT commands group both pieces of unrelated data does not mean > it is a good idea. I fail to see why the DBus and driver API should do the > same mistake as 3GPP 27.007. I already told you I'm open to fixing it. However 27.007 is the only standard we have right now. > > > There are 2 registration states, one reported by CREG and one reported by > > CGREG. Both report essentially the same information, namely registration > > status, lac, cellid and radio access technology. > > > > The way we know an AT-command based modem is attached is when we start > > receiving these CGREG indications (registered/roaming + lac/ci/rat) > > A device cannot attach to GPRS an a different network than the one it is > registered with. I do not see the value of tying those in oFono. The caller > can use the network registration interface, and in fact, I think it should. Different network probably not, but different base station? Again I'm not the expert here either. The API was posted for review back in early September, and Nokia participated in the design. If someone can give a definitive answer we can look into making our API more sane. > > I'm open to suggestions on how to fix this (for instance we can get rid > > of Status, LocationAreaCode, CellId attributes, since they're essentially > > the same as in NetworkRegistration interface), but for now this can be > > easily faked by just re-using the information you're providing to netreg > > atom. > > I could steal that data, but it would be vomitively ugly. Worse, it would > be hide a race condition through the DBus interface. There is no way for me > to request both atomically. What race condition? The attach callback does not mean we're attached at that point, it just means we're trying to. Attached status only comes in once we're 'registered' to GPRS, so you can safely query whatever you need and then call ofono_gprs_status_notify > > Is this where the network requests an attach or are you talking about > > something else? > > No no, I am not talking about network-initiated context *activation*. I am > talking about the requirement from some operator that the device be always > *attached* even if it has no active contexts. Note that the battery impact > is negligible. Also, this is NOT quite the same as attaching when oFono > starts: the device could be outside of the GPRS network; auto-attach will > get it attached as soon as possible. I believe the current API already covers this. Context active state and attached state are tracked separately. Thus you can be attached with no active context, I do it all the time. Can't you just turn on your 'auto- attach' mode when oFono calls 'set_attached' with TRUE and turn off attachment when oFono calls 'set_attached' with FALSE? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
- Message d'origine - > > But there are some more fundamental issues. First, the ISI General Packet > > Data Service does not provide any location informations (roaming/not > > roaming, area code, cell ID). And I must say I don't understand why this is > > part of the GPRS atom. This has nothing to do with packet data. > > That is because 3GPP in their infinite wisdom structured the spec this way. Just because AT commands group both pieces of unrelated data does not mean it is a good idea. I fail to see why the DBus and driver API should do the same mistake as 3GPP 27.007. > There are 2 registration states, one reported by CREG and one reported by > CGREG. Both report essentially the same information, namely registration > status, lac, cellid and radio access technology. > > The way we know an AT-command based modem is attached is when we start > receiving these CGREG indications (registered/roaming + lac/ci/rat) A device cannot attach to GPRS an a different network than the one it is registered with. I do not see the value of tying those in oFono. The caller can use the network registration interface, and in fact, I think it should. I am not an expert on GPRS internals but I guess the protocol does not provide those values, and this is just a misdesign of AT commands. > I'm open to suggestions on how to fix this (for instance we can get rid of > Status, LocationAreaCode, CellId attributes, since they're essentially the > same as in NetworkRegistration interface), but for now this can be easily > faked by just re-using the information you're providing to netreg atom. I could steal that data, but it would be vomitively ugly. Worse, it would be hide a race condition through the DBus interface. There is no way for me to request both atomically. > > Second, I couldn't figure how to handle auto-attach. The ISI protocol > > supports it, but I could not find the driver callback. Thus, I would have > > to force the device into manual mode. This is going to be an issue as some > > operators require auto-attach > > Is this where the network requests an attach or are you talking about > something else? No no, I am not talking about network-initiated context *activation*. I am talking about the requirement from some operator that the device be always *attached* even if it has no active contexts. Note that the battery impact is negligible. Also, this is NOT quite the same as attaching when oFono starts: the device could be outside of the GPRS network; auto-attach will get it attached as soon as possible. Rémi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann > > wrote: > > since we have the upstream GPRS support for MBM and HSO devices, it > > would be great to have this for Phonet, too. I tried to work on the > > patch, but without proper documentation it is impossible. So please > > adapt it to the current upstream and resend it. > > I can't quite implement the current API for ISI modem. For a start, ofono > is currently crashing in setpowered as soon as it sees an ISI modem. Wasn't this fixed by commit ee1e9d14bde006da64d3e9d0c1f61523f113869a? If not, get me a backtrace or a patch. > > But there are some more fundamental issues. First, the ISI General Packet > Data Service does not provide any location informations (roaming/not > roaming, area code, cell ID). And I must say I don't understand why this is > part of the GPRS atom. This has nothing to do with packet data. That is because 3GPP in their infinite wisdom structured the spec this way. There are 2 registration states, one reported by CREG and one reported by CGREG. Both report essentially the same information, namely registration status, lac, cellid and radio access technology. The way we know an AT-command based modem is attached is when we start receiving these CGREG indications (registered/roaming + lac/ci/rat) I'm open to suggestions on how to fix this (for instance we can get rid of Status, LocationAreaCode, CellId attributes, since they're essentially the same as in NetworkRegistration interface), but for now this can be easily faked by just re-using the information you're providing to netreg atom. > > Second, I couldn't figure how to handle auto-attach. The ISI protocol > supports it, but I could not find the driver callback. Thus, I would have > to force the device into manual mode. This is going to be an issue as some > operators require auto-attach Is this where the network requests an attach or are you talking about something else? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann wrote: > since we have the upstream GPRS support for MBM and HSO devices, it > would be great to have this for Phonet, too. I tried to work on the > patch, but without proper documentation it is impossible. So please > adapt it to the current upstream and resend it. I can't quite implement the current API for ISI modem. For a start, ofono is currently crashing in setpowered as soon as it sees an ISI modem. But there are some more fundamental issues. First, the ISI General Packet Data Service does not provide any location informations (roaming/not roaming, area code, cell ID). And I must say I don't understand why this is part of the GPRS atom. This has nothing to do with packet data. Second, I couldn't figure how to handle auto-attach. The ISI protocol supports it, but I could not find the driver callback. Thus, I would have to force the device into manual mode. This is going to be an issue as some operators require auto-attach Also, it prevents optimizing context activation when detached, i.e. "follow on" GPRS attach, which the ISI modem provides. I haven't had time to look at the context stuff yet. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Ismo, > > since we have the upstream GPRS support for MBM and HSO devices, it > > would be great to have this for Phonet, too. I tried to work on the > > patch, but without proper documentation it is impossible. So please > > adapt it to the current upstream and resend it. > > Yes, the GPRS ISI support has been delayed. Because the internal API > between the Ofono GPRS atom and the modem driver was changed, the ISI > driver won't work out of the box. I have been recently quite busy with > other tasks, but I'll try to find the time to do the porting or > preferably get Rémi to do it. :-) Since the ISI GPRS support was > already demonstrated to be working, the actual work amount shouldn't > be too big. I tried it by myself, but without the ISI specification, it is a pretty big effort. So we rely on you guys to do it. Do you have any estimate when this could be achieved. I am asking because this feature is also useful for desktop users wanting to attach their Nokia phone just for Internet access. Better than Dialup and PPP since they would get proper signal strength etc. with it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Marcel, > since we have the upstream GPRS support for MBM and HSO devices, it > would be great to have this for Phonet, too. I tried to work on the > patch, but without proper documentation it is impossible. So please > adapt it to the current upstream and resend it. Yes, the GPRS ISI support has been delayed. Because the internal API between the Ofono GPRS atom and the modem driver was changed, the ISI driver won't work out of the box. I have been recently quite busy with other tasks, but I'll try to find the time to do the porting or preferably get Rémi to do it. :-) Since the ISI GPRS support was already demonstrated to be working, the actual work amount shouldn't be too big. -- Ismo Puustinen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Ismo, > I started working on Ofono GPRS support. > > The patch set contains: > > 1) Documentation describing how an Ofono GPRS D-Bus API would look like. > 2) Common Ofono GPRS support. > 3) Ofono GPRS ISI driver. > 4) Test script for trying out the GPRS functionality. > > Note that the GPRS support is in no way completed -- many things are > still TODO or have rough edges. However, I thought that it would be a > good idea to send the patches to the mailing list to gather comments > and improvement suggestions before finalizing the work. since we have the upstream GPRS support for MBM and HSO devices, it would be great to have this for Phonet, too. I tried to work on the patch, but without proper documentation it is impossible. So please adapt it to the current upstream and resend it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > > It's probably difficult if the PC client is allowed to redefine GPRS > > > contexts, but otherwise oFono should at least be able to report the total > > > tx/rx for the context's it has defined. The BT DUN / USB bridge could > > > call into oFono and trigger a poll of all the stats to update them, e.g. > > > when a BT DUN connection is disconnected. > > > > how should it do this if oFono is not in the mix. If you are using > > Bluetooth DUN and point it to a virtual TTY, then you are out of look. > > If using USB CDC ACM then same applies. > > > > The real solution here is Bluetooth PAN and USB CDC Ether which do > > properly interact with the networking stack. > > When we have patched all the Windows PC of the world, we can consider it. my approach would be to try and see how far we get this pushing towards PAN and CDC Ether :) > In the mean time, AT+PPP emulation is required. Some modems do provide data > counters including that. I've seen it as a requirement that I would rather > have avoided but could not. It's ugly and arguably stupid, but required > anyway. In fact, if Ofono won't do it, ConnMan will have to, which is > probably > by all means worse. Actually it is worth for high-speed modems with a network interface and no internal PPP emulation, we would have to do that emulation somewhere in the host stack. And now my brain hurts :( > You can argue that it should be a driver-specific feature, but it has to be > there. Hence, I would guess that more than one driver will support > eventually, > at which point it should probably be in the common API. We have to figure something out, but right I would prefer if we GPRS up and running and after that tackle the statistics part. Since without GPRS, we don't need the statistics ;) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le jeudi 3 septembre 2009 00:01:03 Marcel Holtmann, vous avez écrit : > > It's probably difficult if the PC client is allowed to redefine GPRS > > contexts, but otherwise oFono should at least be able to report the total > > tx/rx for the context's it has defined. The BT DUN / USB bridge could > > call into oFono and trigger a poll of all the stats to update them, e.g. > > when a BT DUN connection is disconnected. > > how should it do this if oFono is not in the mix. If you are using > Bluetooth DUN and point it to a virtual TTY, then you are out of look. > If using USB CDC ACM then same applies. > > The real solution here is Bluetooth PAN and USB CDC Ether which do > properly interact with the networking stack. When we have patched all the Windows PC of the world, we can consider it. In the mean time, AT+PPP emulation is required. Some modems do provide data counters including that. I've seen it as a requirement that I would rather have avoided but could not. It's ugly and arguably stupid, but required anyway. In fact, if Ofono won't do it, ConnMan will have to, which is probably by all means worse. You can argue that it should be a driver-specific feature, but it has to be there. Hence, I would guess that more than one driver will support eventually, at which point it should probably be in the common API. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Denis, > > > >> The reason is simple, Nokia modems suspend GPRS when scanning (or > > > >> registering), simply because the operation will take roughly three > > > >> times as long with GPRS attached. You will find this feature in > > > >> current phones, too. > > > > > > > > Then ideally you should have two scan modes, periodic and user > > > > initiated. For periodic mode we don't care how long it takes. > > > > > > +1 > > > > Sounds like a plan. So we do need an /etc/ofono/main.conf :) > > So my current thinking is to introduce a method to NetworkRegistration > property called 'ProposeOperatorScan' and a new property called > 'OperatorScanInterval'. The driver api can then support a (non-standard > *gasp*) option to say whether this scan was initiated actively or not. > > Maybe the Nokia modems can use this information not to drop the GPRS link if > it isn't an active scan being performed. I really prefer if we put this into /etc/ofono/main.conf since the UI should not configure this at all. It is more a one time setting based on what the integrator expects as a behavior. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
Hi Waldo, > > > > I know why you want this, but I'm still against the counter being an > > > > oFono driver API. There needs to be a proper kernel interface that > > > > signals the application when an interface has gone away with the rx/tx > > > > details. This way we handle this generically for all modems without > > > > relying on some intrinsic hardware capabilities. > > > > > > This still doesn't solve the case where the modem is accessed from a PC > > > client and forwards PPP data as that data will not go through any > > > network interface, e.g. BT DUN or USB tethering. > > > > The cases you describe imply that oFono is not even in control of the gprs > > context. How would we track/report the tx/rx statistics in that case? > > It's probably difficult if the PC client is allowed to redefine GPRS > contexts, but otherwise oFono should at least be able to report the total > tx/rx for the context's it has defined. The BT DUN / USB bridge could call > into oFono and trigger a poll of all the stats to update them, e.g. when a BT > DUN connection is disconnected. how should it do this if oFono is not in the mix. If you are using Bluetooth DUN and point it to a virtual TTY, then you are out of look. If using USB CDC ACM then same applies. The real solution here is Bluetooth PAN and USB CDC Ether which do properly interact with the networking stack. > > > The modem is really in the best position to provide the most reliable > > > information on data usage. You can still use statistics from the network > > > interfaces as a fall-back in case the modem can not provide this > > > information. > > > > I don't disagree, but not every modem can track these statistics and this > > isn't described by 27.007. I suggest the initial support should be > > enabled by the modem driver implementing a custom D-Bus interface and > > expose these details however it wishes. > > The modem driver has no desires of its own :-) It really comes down to what > the UI needs and I doubt that the UI wants to deal with this on a modem by > modem basis, but sure it's a possibility. The current consent is that we might send a one time signal with all statistics details once the interface goes away. Or we can make the kernel help us here. However I prefer that we sit this out a little and play with what is possible before knocking down an API. I am not even sure what different hardware would give us and how things need to work. I don't see us having enough information to understand what is needed from a hardware, driver or oFono core point of view. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > Actually this one is missing from the API proposal. Marcel already wanted > > the context type (internet, mms, wap, etc) information. I've updated the > > proposed API in git. > > This is not going to work. > > Depending on the operator, you may have more than one "type" for a single > context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. > Internet with only Web and Internet with full IP). we might need some extra work here and define what we want. I am confident that we can break this down to something useful. Worst case we something free form. > > As discussed previously, we want oFono to manage this data, since it can do > > this by using the IMSI. So if you insert a different operator SIM your APN > > settings are magically updated for that operator. > > I have a feeling this does not work either. If I upgrade my subscription, the > APN may change while not the IMSI, no? We can update these details at any time. Storing them on a per ISMI basis is a good idea and something new that oFono does (as far as what I have seen). So if you switch SIM cards, then you don't have to worry about anything when traveling. It does the right thing you configured. Especially with the devices like the Nokia netbook and the iPhone where you can easily switch SIM cards without power on/off this will come in handy. If an upgrade of the subscription needs manual interaction from the user or an operator message to update the settings, then that is fine. Since the user did something to begin with. So they are aware of that something changed (hope the operator told them). While just switching a SIM card and by accident using a wrong APN and causing expensive roaming would be a worse thing. Especially since there is an expectation from the user when switching SIM cards. > > > In my proposal the "Status" variable was a three-state variable, > > > having the states "attached", "detached" and "suspended". "Suspended" > > > was specified to mean that the GPRS was attached, but temporarily not > > > available (for instance because of a 2G phone call or temporary loss > > > of cellular connectivity). In the IRC discussion someone said that > > > this property would not be part of Denis's API because the tri-state > > > variables were bad and the "suspended" status was not supported by > > > > So the general rule is that if a feature isn't explicitly allowed in > > 27.007, we do not support it. There are exceptions to this of course. > > 27.007 only supports two states for context: activated and deactivated. > > Our general rule is that if we have a UI requirement, or better an actual use > case for it, we support it. Suspended GPRS fits both. Can you share these UI requirements with us. > > > spec 27.007. However, the problem is that Maemo 5 already has UI > > > support for indicating that the connection is suspended, and that > > > makes it harder to drop the feature. Could the "suspended" status enum > > > still be left there, and just have the modems that don't support the > > > feature to never go to "suspended" mode? > > > > I'd rather not. > > > > If this feature is really required, then some sort of heuristic can be > > applied. (e.g. Powered on, Attached on, but context is deactivated most > > likely means temporary unavailability of resources) > > Is this some kind of joke? Don't you know the difference between pause and > stop on your MP3 player and between suspend to memory and power off on your > computer? > > Second guessing does not fit in my definition of "easy to use self- > documenting" for an API. > > > This really belong in the kernel. Only the kernel can reliably know when a > > network interface has been brought down and notify the interested > > applications with the statistics. > > You're missing the point. > > Yes, any body can extract the statistics for a running context. But data > counters are cumulating. To compute the sum properly, there are but two > options: > # Either the GPRS middleware requests kernel per-interface statistics right > before destroying the interface, and sums with the earlier total. > # Or the modem does it internally. > > There is no way some random userland interface application can do it just by > requesting the kernel, since it cannot know when to request those statistics. So my 2 cents here are that whatever so modem does for statistics it should match the details its exports via the networking interface. And on the kernel part and destroyed interface, as I mentioned, we need to discuss this with the kernel guys. I wanna get an answer what can be done to help us. We have most kernel guys at netconf in Portland in three weeks and I gonna check with them. > > Nokia hardware supports this explicitly, but many others don't. > > That's irrelevant. Hardware support helps in the sense that it can include > statistics for contexts external to Ofono. If the hardware does not support > it, then it needs to be done
Re: GPRS support for Ofono
Hi Marcel, > > >> The reason is simple, Nokia modems suspend GPRS when scanning (or > > >> registering), simply because the operation will take roughly three > > >> times as long with GPRS attached. You will find this feature in > > >> current phones, too. > > > > > > Then ideally you should have two scan modes, periodic and user > > > initiated. For periodic mode we don't care how long it takes. > > > > +1 > > Sounds like a plan. So we do need an /etc/ofono/main.conf :) So my current thinking is to introduce a method to NetworkRegistration property called 'ProposeOperatorScan' and a new property called 'OperatorScanInterval'. The driver api can then support a (non-standard *gasp*) option to say whether this scan was initiated actively or not. Maybe the Nokia modems can use this information not to drop the GPRS link if it isn't an active scan being performed. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
Hi Waldo, > > > > I am still not seeing the point in what suspended will do for us and > > > > the UI. And that Maemo 5 exposed such a state in the UI is not an > > > > argument to keep doing it. I asked this before, what are we suppose to > > > > be doing when we get signaled suspended? > > > > > > User, as well as intelligent (connectivity-aware) applications, need to > > > know about this so that they understand why "Internet" is momentarily > > > broken. It's as simple as that. > > +1 they need to know if they can do something useful with this information. If not, then this state is just pointless. However the D-Bus API is the wrong location for this detail. > > > Oh we could also use the network device carrier flag, and then use > > > Netlink (and we probably should do that too), but we all know how > > > horrible Netlink is from userland. > > > > Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some > > suspended state. > > IF_OPER_DORMANT seems a more accurate reflection of the state. Yep. That sounds good. We don't use that in ConnMan right now, but that can be fixed of course. I still need to figure out what we are suppose to do when this gets signaled to us. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, > >> AFAIK, attach status of GPRS has both regulatory aspects to consider > >> (some operators require always attached vs. some prohibit it) as well > >> as power consumption issues (auto-attach might draw more power than > >> on-demand, although there's an inverse effect on latency). These are > >> issues you need to take into account, and higher layers in the stack > >> definitely *need* to be aware of as well. Also, I don' t think oFono > >> is the correct place for these decisions -> better expose a necessary > >> API and let upper layers deal with it. > > > > I know you guys are coming from mobile phone perspective, but that one isn't > > the only scenario. We have netbooks/laptops with gprs data cards to > > consider > > as well. Hardcoding operator requirements is also not an option, since SIM > > cards can be changed. > > > > I fundamentally disagree that the logic should be in the higher layers. > > oFono > > has all the information to handle this, and can be hinted on what is > > appropriate behavior easily enough. oFono should simply store the > > auto-attach > > preferences in its IMSI-indexed preference store. The operator can > > bootstrap > > these preferences if required. > > Operator requirements were only half of the story. You need to be able > to disable auto-attach in low power conditions, and this logic > definitely doesn't belong in oFono. This applies equally well to > mobile phones as it does to laptops/netbooks. this a different requirement. Where do you get your low power information from? I would prefer that we add a plugin that gets informed of this low power situation and then is able to adjust such things. I am against exposing this in user application/UI API. I am with you that such requirements have to be met, but not via the D-Bus API. So these kind of policy details are device/manufacturer specific and having a custom plugins that can be enabled by the integrator sounds best to me if a config file is not flexible enough. > >> In general, I appreciate the attempt to hide ugly details from > >> applications, but unfortunately some things can't well be hidden. > >> Another unrelated, but similar issue is network scanning. It just > >> isn't going to work without us exposing it in the D-Bus API > >> explicitly. > >> > > > > Modem drivers will have some control over whether the scan is performed > > automatically, but denying the capability for everyone is not the right > > thing > > to do either. > > Agree, and I don't think that was what I was suggesting either. > > >> The reason is simple, Nokia modems suspend GPRS when scanning (or > >> registering), simply because the operation will take roughly three > >> times as long with GPRS attached. You will find this feature in > >> current phones, too. > > > > Then ideally you should have two scan modes, periodic and user initiated. > > For > > periodic mode we don't care how long it takes. > > +1 Sounds like a plan. So we do need an /etc/ofono/main.conf :) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
> > > I know why you want this, but I'm still against the counter being an > > > oFono driver API. There needs to be a proper kernel interface that > > > signals the application when an interface has gone away with the rx/tx > > > details. This way we handle this generically for all modems without > > > relying on some intrinsic hardware capabilities. > > > > This still doesn't solve the case where the modem is accessed from a PC > > client and forwards PPP data as that data will not go through any > > network interface, e.g. BT DUN or USB tethering. > > The cases you describe imply that oFono is not even in control of the gprs > context. How would we track/report the tx/rx statistics in that case? It's probably difficult if the PC client is allowed to redefine GPRS contexts, but otherwise oFono should at least be able to report the total tx/rx for the context's it has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the stats to update them, e.g. when a BT DUN connection is disconnected. > > The modem is really in the best position to provide the most reliable > > information on data usage. You can still use statistics from the network > > interfaces as a fall-back in case the modem can not provide this > > information. > > I don't disagree, but not every modem can track these statistics and this > isn't described by 27.007. I suggest the initial support should be > enabled by the modem driver implementing a custom D-Bus interface and > expose these details however it wishes. The modem driver has no desires of its own :-) It really comes down to what the UI needs and I doubt that the UI wants to deal with this on a modem by modem basis, but sure it's a possibility. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Waldo, > > I know why you want this, but I'm still against the counter being an > > oFono driver API. There needs to be a proper kernel interface that > > signals the application when an interface has gone away with the rx/tx > > details. This way we handle this generically for all modems without > > relying on some intrinsic hardware capabilities. > > This still doesn't solve the case where the modem is accessed from a PC > client and forwards PPP data as that data will not go through any network > interface, e.g. BT DUN or USB tethering. The cases you describe imply that oFono is not even in control of the gprs context. How would we track/report the tx/rx statistics in that case? > > The modem is really in the best position to provide the most reliable > information on data usage. You can still use statistics from the network > interfaces as a fall-back in case the modem can not provide this > information. I don't disagree, but not every modem can track these statistics and this isn't described by 27.007. I suggest the initial support should be enabled by the modem driver implementing a custom D-Bus interface and expose these details however it wishes. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
> > > I am still not seeing the point in what suspended will do for us and > > > the UI. And that Maemo 5 exposed such a state in the UI is not an > > > argument to keep doing it. I asked this before, what are we suppose to > > > be doing when we get signaled suspended? > > > > User, as well as intelligent (connectivity-aware) applications, need to > > know about this so that they understand why "Internet" is momentarily > > broken. It's as simple as that. +1 > > Oh we could also use the network device carrier flag, and then use > > Netlink (and we probably should do that too), but we all know how > > horrible Netlink is from userland. > > Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some > suspended state. IF_OPER_DORMANT seems a more accurate reflection of the state. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
> > > This really belong in the kernel. Only the kernel can reliably know > > > when a network interface has been brought down and notify the > > > interested applications with the statistics. > > > > You're missing the point. > > > > Yes, any body can extract the statistics for a running context. But data > > counters are cumulating. To compute the sum properly, there are but two > > options: > > # Either the GPRS middleware requests kernel per-interface statistics > > right before destroying the interface, and sums with the earlier total. > > # Or the modem does it internally. > > I know why you want this, but I'm still against the counter being an oFono > driver API. There needs to be a proper kernel interface that signals the > application when an interface has gone away with the rx/tx details. This > way we handle this generically for all modems without relying on some > intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit : > > Actually this one is missing from the API proposal. Marcel already > > wanted the context type (internet, mms, wap, etc) information. I've > > updated the proposed API in git. > > This is not going to work. > > Depending on the operator, you may have more than one "type" for a single > context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. > Internet with only Web and Internet with full IP). Worst case we make the field completely freeform. Right now we really only care about "internet" type for connman. > > > As discussed previously, we want oFono to manage this data, since it can > > do this by using the IMSI. So if you insert a different operator SIM > > your APN settings are magically updated for that operator. > > I have a feeling this does not work either. If I upgrade my subscription, > the APN may change while not the IMSI, no? Yes, but then you will probably receive an SMS/OTA message with new connection details. Which either oFono or some external application will apply to your GPRS settings. > > This really belong in the kernel. Only the kernel can reliably know when > > a network interface has been brought down and notify the interested > > applications with the statistics. > > You're missing the point. > > Yes, any body can extract the statistics for a running context. But data > counters are cumulating. To compute the sum properly, there are but two > options: > # Either the GPRS middleware requests kernel per-interface statistics right > before destroying the interface, and sums with the earlier total. > # Or the modem does it internally. I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. The rx/tx counter not being reported via PropertyChanged is also a bad idea since it breaks our API conventions. I can deal with a one-time signal being emitted when the interface has gone away though. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, > Hi Denis, > > 2009/9/2 Denis Kenzior : > > So the general rule is that if a feature isn't explicitly allowed in > > 27.007, we do not support it. There are exceptions to this of course. > > 27.007 only supports two states for context: activated and deactivated. > > Ahem. Just like access selection mode is not in 27.007, yet Nokia has > it, and most AT modems have proprietary commands to query and set it > [1]. Maybe you call that the necessary exception to the rule, but I > think we might as well change the rule to: So my stance on BandSelection is that we want a standard interface _if and only if_ we can support it reliably across the majority of modems. You might still find me telling every modem manufacturer to simply implement their own BandSelection interface if this cannot be done. The same goes for Neighbor Cell Info or any other stuff that isn't mandated by 27.007. > > >> spec 27.007. However, the problem is that Maemo 5 already has UI > >> support for indicating that the connection is suspended, and that > >> makes it harder to drop the feature. Could the "suspended" status enum > >> still be left there, and just have the modems that don't support the > >> feature to never go to "suspended" mode? > > > > I'd rather not. > > > > If this feature is really required, then some sort of heuristic can be > > applied. (e.g. Powered on, Attached on, but context is deactivated most > > likely means temporary unavailability of resources) > > You want the UI to implement this heuristic, when the modem plugin has > explicit knowledge of that state, but isn't telling? Please explain > how that makes the UI simpler? Then expose this signal on Nokia-only interface and be done with it. Why does everything have to be part of the oFono official APIs? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
2009/9/2 Denis Kenzior : >> AFAIK, attach status of GPRS has both regulatory aspects to consider >> (some operators require always attached vs. some prohibit it) as well >> as power consumption issues (auto-attach might draw more power than >> on-demand, although there's an inverse effect on latency). These are >> issues you need to take into account, and higher layers in the stack >> definitely *need* to be aware of as well. Also, I don' t think oFono >> is the correct place for these decisions -> better expose a necessary >> API and let upper layers deal with it. > > I know you guys are coming from mobile phone perspective, but that one isn't > the only scenario. We have netbooks/laptops with gprs data cards to consider > as well. Hardcoding operator requirements is also not an option, since SIM > cards can be changed. > > I fundamentally disagree that the logic should be in the higher layers. oFono > has all the information to handle this, and can be hinted on what is > appropriate behavior easily enough. oFono should simply store the auto-attach > preferences in its IMSI-indexed preference store. The operator can bootstrap > these preferences if required. Operator requirements were only half of the story. You need to be able to disable auto-attach in low power conditions, and this logic definitely doesn't belong in oFono. This applies equally well to mobile phones as it does to laptops/netbooks. >> In general, I appreciate the attempt to hide ugly details from >> applications, but unfortunately some things can't well be hidden. >> Another unrelated, but similar issue is network scanning. It just >> isn't going to work without us exposing it in the D-Bus API >> explicitly. >> > > Modem drivers will have some control over whether the scan is performed > automatically, but denying the capability for everyone is not the right thing > to do either. Agree, and I don't think that was what I was suggesting either. >> The reason is simple, Nokia modems suspend GPRS when scanning (or >> registering), simply because the operation will take roughly three >> times as long with GPRS attached. You will find this feature in >> current phones, too. > > Then ideally you should have two scan modes, periodic and user initiated. For > periodic mode we don't care how long it takes. +1 Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit : > Actually this one is missing from the API proposal. Marcel already wanted > the context type (internet, mms, wap, etc) information. I've updated the > proposed API in git. This is not going to work. Depending on the operator, you may have more than one "type" for a single context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. Internet with only Web and Internet with full IP). > As discussed previously, we want oFono to manage this data, since it can do > this by using the IMSI. So if you insert a different operator SIM your APN > settings are magically updated for that operator. I have a feeling this does not work either. If I upgrade my subscription, the APN may change while not the IMSI, no? > > In my proposal the "Status" variable was a three-state variable, > > having the states "attached", "detached" and "suspended". "Suspended" > > was specified to mean that the GPRS was attached, but temporarily not > > available (for instance because of a 2G phone call or temporary loss > > of cellular connectivity). In the IRC discussion someone said that > > this property would not be part of Denis's API because the tri-state > > variables were bad and the "suspended" status was not supported by > > So the general rule is that if a feature isn't explicitly allowed in > 27.007, we do not support it. There are exceptions to this of course. > 27.007 only supports two states for context: activated and deactivated. Our general rule is that if we have a UI requirement, or better an actual use case for it, we support it. Suspended GPRS fits both. > > spec 27.007. However, the problem is that Maemo 5 already has UI > > support for indicating that the connection is suspended, and that > > makes it harder to drop the feature. Could the "suspended" status enum > > still be left there, and just have the modems that don't support the > > feature to never go to "suspended" mode? > > I'd rather not. > > If this feature is really required, then some sort of heuristic can be > applied. (e.g. Powered on, Attached on, but context is deactivated most > likely means temporary unavailability of resources) Is this some kind of joke? Don't you know the difference between pause and stop on your MP3 player and between suspend to memory and power off on your computer? Second guessing does not fit in my definition of "easy to use self- documenting" for an API. > This really belong in the kernel. Only the kernel can reliably know when a > network interface has been brought down and notify the interested > applications with the statistics. You're missing the point. Yes, any body can extract the statistics for a running context. But data counters are cumulating. To compute the sum properly, there are but two options: # Either the GPRS middleware requests kernel per-interface statistics right before destroying the interface, and sums with the earlier total. # Or the modem does it internally. There is no way some random userland interface application can do it just by requesting the kernel, since it cannot know when to request those statistics. > Nokia hardware supports this explicitly, but many others don't. That's irrelevant. Hardware support helps in the sense that it can include statistics for contexts external to Ofono. If the hardware does not support it, then it needs to be done manually in the GPRS middleware. That won't make the requirement go away. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, > > We are not going to expose Attach() or Detach() method. As explained > > there are global anyway and so pointless to expose. This can be handled > > in the background without bothering the higher level application with > > these details. > > AFAIK, attach status of GPRS has both regulatory aspects to consider > (some operators require always attached vs. some prohibit it) as well > as power consumption issues (auto-attach might draw more power than > on-demand, although there's an inverse effect on latency). These are > issues you need to take into account, and higher layers in the stack > definitely *need* to be aware of as well. Also, I don' t think oFono > is the correct place for these decisions -> better expose a necessary > API and let upper layers deal with it. I know you guys are coming from mobile phone perspective, but that one isn't the only scenario. We have netbooks/laptops with gprs data cards to consider as well. Hardcoding operator requirements is also not an option, since SIM cards can be changed. I fundamentally disagree that the logic should be in the higher layers. oFono has all the information to handle this, and can be hinted on what is appropriate behavior easily enough. oFono should simply store the auto-attach preferences in its IMSI-indexed preference store. The operator can bootstrap these preferences if required. > > In general, I appreciate the attempt to hide ugly details from > applications, but unfortunately some things can't well be hidden. > Another unrelated, but similar issue is network scanning. It just > isn't going to work without us exposing it in the D-Bus API > explicitly. > Modem drivers will have some control over whether the scan is performed automatically, but denying the capability for everyone is not the right thing to do either. > The reason is simple, Nokia modems suspend GPRS when scanning (or > registering), simply because the operation will take roughly three > times as long with GPRS attached. You will find this feature in > current phones, too. Then ideally you should have two scan modes, periodic and user initiated. For periodic mode we don't care how long it takes. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Denis, 2009/9/2 Denis Kenzior : > So the general rule is that if a feature isn't explicitly allowed in 27.007, > we do not support it. There are exceptions to this of course. 27.007 only > supports two states for context: activated and deactivated. Ahem. Just like access selection mode is not in 27.007, yet Nokia has it, and most AT modems have proprietary commands to query and set it [1]. Maybe you call that the necessary exception to the rule, but I think we might as well change the rule to: "If a feature is explicitly requested by users of oFono, and can be reasonably provided by modems that have it without braking those that don't have it, it will be supported. And 27.007 can go fsck itself." ;-) >> spec 27.007. However, the problem is that Maemo 5 already has UI >> support for indicating that the connection is suspended, and that >> makes it harder to drop the feature. Could the "suspended" status enum >> still be left there, and just have the modems that don't support the >> feature to never go to "suspended" mode? > > I'd rather not. > > If this feature is really required, then some sort of heuristic can be > applied. (e.g. Powered on, Attached on, but context is deactivated most > likely means temporary unavailability of resources) You want the UI to implement this heuristic, when the modem plugin has explicit knowledge of that state, but isn't telling? Please explain how that makes the UI simpler? Cheers, Aki [1] http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Ismo, > This is a philosophical difference from the provisioning point of > view. An operator will likely support multiple configured access > points, and the provisioning program should know their purpose from > the configuration file (internet/MMS/WAP/...). This metadata is not > there in the Ofono context, meaning that the provisioning program > needs to store somewhere else the mapping between Ofono context object > paths and the neccessary metadata. This begs the question: why not > store all connection data (APN, authentication data, other metadata) > to this external store in the first place? Actually this one is missing from the API proposal. Marcel already wanted the context type (internet, mms, wap, etc) information. I've updated the proposed API in git. As discussed previously, we want oFono to manage this data, since it can do this by using the IMSI. So if you insert a different operator SIM your APN settings are magically updated for that operator. > In my proposal the "Status" variable was a three-state variable, > having the states "attached", "detached" and "suspended". "Suspended" > was specified to mean that the GPRS was attached, but temporarily not > available (for instance because of a 2G phone call or temporary loss > of cellular connectivity). In the IRC discussion someone said that > this property would not be part of Denis's API because the tri-state > variables were bad and the "suspended" status was not supported by So the general rule is that if a feature isn't explicitly allowed in 27.007, we do not support it. There are exceptions to this of course. 27.007 only supports two states for context: activated and deactivated. > spec 27.007. However, the problem is that Maemo 5 already has UI > support for indicating that the connection is suspended, and that > makes it harder to drop the feature. Could the "suspended" status enum > still be left there, and just have the modems that don't support the > feature to never go to "suspended" mode? I'd rather not. If this feature is really required, then some sort of heuristic can be applied. (e.g. Powered on, Attached on, but context is deactivated most likely means temporary unavailability of resources) > > Still one difference to my proposal was the dropping of the TX and RX > byte counts, and the explanation that those statistics would be > handled by the upper layers by reading the values from the network > interface. I mentioned the problem where the connection was terminated > by the network and the network interface was brought down before the > upper layer had a chance to read the values. After giving the matter > some thought, I still feel that for this reason the modem driver would > need to get the TX/RX data and send it to the upper levels, if at all > possible. Since many operators charge by the amount of data > transferred, not losing the TX/RX data is quite crucial. At least > Nokia phones have a GPRS data counter feature, that is supposed to > show the transferred data. This said, I know that not all modem > drivers can get the data from a connection that has been terminated by > the network, but that does not mean that the modem drivers that can > get the data should just discard it. This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. Nokia hardware supports this explicitly, but many others don't. I don't want nasty kludges inside oFono to enable this. > > Btw, is the context API missing the PDP type (IPv4 or IPv6)? I left this out explicitly since I've never seen anything besides "IP" being used. But we can add this easily enough if there's need. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > I mentioned that already. We do wanna store something like Type that > > says internet, mms, wap etc. The only comment here was that for network > > initiated context we have no idea of its intent. > > And we do not want to. > > >> The attachment to the GPRS network in this proposal is bit vague. To > >> my understanding, to attach the GPRS you need to set "Powered" > >> property on and "RoamingAllowed" on. To detach you need to set the > >> "Powered" property off. Since attaching can take a long time (or > >> fail), does this mean that the attach errors are handled in the > >> "Powered" property setter callback? Or what happens when (during > >> roaming) the "Powered" is already on and the user puts the > >> "RoamingAllowed" on -- where are the attach errors handled? I kind of > >> think that it might be a better idea to just expose the GPRS > >> registration status and the attach status, and let a higher level > >> component explicitly set the attach/detach with either a readwrite > >> property or Attach() and Detach() methods. > > > > Powered = on and RoamingAllowed = yes and Roaming = true will lead to > > auto-attach. > > That's just _idiotic_ from the naming perspective. > > A modem can have radio on or off. Whether this is done by completely > powering the modem off, or by going into some kind of flight mode, is > driver-specific. Hence the "powered" name is semantically wrong. When > possible, it's actually best to keep the modem in flight mode, so that e.g. > the SIM is still usable. > > The story is basically the same with roaming. Roaming means you are outside > your home network. It does not mean that you want to auto-attach or not. > Some people _never_ want to auto-attach, and some people _always_ want to > auto-attach. In fact, different operators have different requirements with > that regard. Sure, some people want to auto-attach if and only if not > roaming. Given that roaming is not just about GPRS, the name is wrong and > confusing. But more importantly, we need t support turning the radio on > while in the home network yet _not_ attach automatically. This has operator > requirements as well as power saving implications. you did read the API docs Denis send around? These are not global Powered and RoamingAllowed properties. They are specific to the GPRS Manager and thus have specific meaning in that context. It has nothing to do with flight mode or radio off. And for the different operator policy/behavior, that should be configured via config option and not via D-Bus. The integrator should make a choice. It it is a list of mappings of operator = attach policy, then that is also fine. > > We are not going to expose Attach() or Detach() method. > > And we are going to expose it. And for what good is this. So we have two applications fighting about Attach and Detach and some weird policy somewhere upper in the stack with no real sense on what is happening. Sorry but I am not buying this at all. If the only argument is that different providers require different auto-attach policies then we have that as described via a config option and be done with it. Otherwise I like to see real examples where something like ConnMan, an MMS application or any other application need control over the attach status. > > I am still not seeing the point in what suspended will do for us and the > > UI. And that Maemo 5 exposed such a state in the UI is not an argument > > to keep doing it. I asked this before, what are we suppose to be doing > > when we get signaled suspended? > > User, as well as intelligent (connectivity-aware) applications, need to > know about this so that they understand why "Internet" is momentarily > broken. It's as simple as that. > > Oh we could also use the network device carrier flag, and then use Netlink > (and we probably should do that too), but we all know how horrible Netlink > is from userland. Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some suspended state. > (...) > > This is for ConnMan or similar to figure out. And we can always count > > via netfilter or some other facility. Counting inside oFono makes no > > sense. However we could send out a statistics signal before taking the > > interface down if it would be really needed. Making it part of the > > properties and having to poll for it is wrong. > > This has legal(ish) implications related to charging. Skipping this is not > exactly an option (for a device vendor). I actually agree that this is ugly > in some ways. In theory, I don't really care if Ofono or the over-lying > connection manager takes care of it. *But* we even need to collect > statistics for contexts not handled in Ofono (e.g. Windows PC tethering). > And I doubt that Connman would be able to do that properly. > > It's ugly and annoying, but we have to suck it up. As I mentioned it before. We figure something out. We do have the same problem for all hotplug network devices. Especially with hotplug 3G
Re: GPRS support for Ofono
On Wed, 02 Sep 2009 05:46:31 -0700, Marcel Holtmann wrote: >> You will find that practically every Nokia phone behaves this way, >> i.e., you make a call in 2G, and the UI will inform you that GPRS is >> suspended while on call. > > So what is the difference signaling a disconnect and re-connect to the > application? It's like pausing or stopping your media player. >> For some of these features, there is no question whether or not we >> need them. I think you should be listening closely for the >> requirements we post, because this isn't something we *think* might be >> needed some day -- this is stuff that we've implemented and will ship, >> and expect to ship in the future. > > Then please give examples. I asked this on IRC. I have never used > Secondary PDP Context before. Same goes for network initiated contexts. Neither did I. OTOH, I did see annoying data counter requirements, and I did see suspended mode. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, > > Powered = on and RoamingAllowed = yes and Roaming = true will lead to > > auto-attach. > > > > Powered = on and RoamingAllowed = no and Roaming = true will lead to > > detach. > > > > Powered = on and Roaming = false will lead to auto-attach. > > > > Powered = off will lead to detach. > > Why is auto-attach dependent on roaming? power consumption. No need to attach if you don't wanna allow data roaming. > > We are not going to expose Attach() or Detach() method. As explained > > there are global anyway and so pointless to expose. This can be handled > > in the background without bothering the higher level application with > > these details. > > AFAIK, attach status of GPRS has both regulatory aspects to consider > (some operators require always attached vs. some prohibit it) as well > as power consumption issues (auto-attach might draw more power than > on-demand, although there's an inverse effect on latency). These are > issues you need to take into account, and higher layers in the stack > definitely *need* to be aware of as well. Also, I don' t think oFono > is the correct place for these decisions -> better expose a necessary > API and let upper layers deal with it. I disagree. We can have a config option that always attaches or attached on demand, but this should not be exposed to any higher level applications. > In general, I appreciate the attempt to hide ugly details from > applications, but unfortunately some things can't well be hidden. > Another unrelated, but similar issue is network scanning. It just > isn't going to work without us exposing it in the D-Bus API > explicitly. > > The reason is simple, Nokia modems suspend GPRS when scanning (or > registering), simply because the operation will take roughly three > times as long with GPRS attached. You will find this feature in > current phones, too. > > Now, there is no way we can have GPRS suspend without warning just > because the stack deems it necessary to scan for networks. Again the > intention is good, but the end result not so good. I don't want to > start patching oFono to support this type of basic stuff. I mentioned this before. We might need to add a config option to allow integrators choose different behavior. > >> In my proposal the "Status" variable was a three-state variable, > >> having the states "attached", "detached" and "suspended". "Suspended" > >> was specified to mean that the GPRS was attached, but temporarily not > >> available (for instance because of a 2G phone call or temporary loss > >> of cellular connectivity). In the IRC discussion someone said that > >> this property would not be part of Denis's API because the tri-state > >> variables were bad and the "suspended" status was not supported by > >> spec 27.007. However, the problem is that Maemo 5 already has UI > >> support for indicating that the connection is suspended, and that > >> makes it harder to drop the feature. Could the "suspended" status enum > >> still be left there, and just have the modems that don't support the > >> feature to never go to "suspended" mode? > > > > I am still not seeing the point in what suspended will do for us and the > > UI. And that Maemo 5 exposed such a state in the UI is not an argument > > to keep doing it. I asked this before, what are we suppose to be doing > > when we get signaled suspended? > > You will find that practically every Nokia phone behaves this way, > i.e., you make a call in 2G, and the UI will inform you that GPRS is > suspended while on call. So what is the difference signaling a disconnect and re-connect to the application? > >> Still one difference to my proposal was the dropping of the TX and RX > >> byte counts, and the explanation that those statistics would be > >> handled by the upper layers by reading the values from the network > >> interface. I mentioned the problem where the connection was terminated > >> by the network and the network interface was brought down before the > >> upper layer had a chance to read the values. After giving the matter > >> some thought, I still feel that for this reason the modem driver would > >> need to get the TX/RX data and send it to the upper levels, if at all > >> possible. Since many operators charge by the amount of data > >> transferred, not losing the TX/RX data is quite crucial. At least > >> Nokia phones have a GPRS data counter feature, that is supposed to > >> show the transferred data. This said, I know that not all modem > >> drivers can get the data from a connection that has been terminated by > >> the network, but that does not mean that the modem drivers that can > >> get the data should just discard it. > > > > This is for ConnMan or similar to figure out. And we can always count > > via netfilter or some other facility. Counting inside oFono makes no > > sense. However we could send out a statistics signal before taking the > > interface down if it would be really needed. Making it part of the > > properties and havi
Re: GPRS support for Ofono
On Wed, 02 Sep 2009 05:02:46 -0700, Marcel Holtmann wrote: > I mentioned that already. We do wanna store something like Type that > says internet, mms, wap etc. The only comment here was that for network > initiated context we have no idea of its intent. And we do not want to. >> The attachment to the GPRS network in this proposal is bit vague. To >> my understanding, to attach the GPRS you need to set "Powered" >> property on and "RoamingAllowed" on. To detach you need to set the >> "Powered" property off. Since attaching can take a long time (or >> fail), does this mean that the attach errors are handled in the >> "Powered" property setter callback? Or what happens when (during >> roaming) the "Powered" is already on and the user puts the >> "RoamingAllowed" on -- where are the attach errors handled? I kind of >> think that it might be a better idea to just expose the GPRS >> registration status and the attach status, and let a higher level >> component explicitly set the attach/detach with either a readwrite >> property or Attach() and Detach() methods. > > Powered = on and RoamingAllowed = yes and Roaming = true will lead to > auto-attach. That's just _idiotic_ from the naming perspective. A modem can have radio on or off. Whether this is done by completely powering the modem off, or by going into some kind of flight mode, is driver-specific. Hence the "powered" name is semantically wrong. When possible, it's actually best to keep the modem in flight mode, so that e.g. the SIM is still usable. The story is basically the same with roaming. Roaming means you are outside your home network. It does not mean that you want to auto-attach or not. Some people _never_ want to auto-attach, and some people _always_ want to auto-attach. In fact, different operators have different requirements with that regard. Sure, some people want to auto-attach if and only if not roaming. Given that roaming is not just about GPRS, the name is wrong and confusing. But more importantly, we need t support turning the radio on while in the home network yet _not_ attach automatically. This has operator requirements as well as power saving implications. > We are not going to expose Attach() or Detach() method. And we are going to expose it. > I am still not seeing the point in what suspended will do for us and the > UI. And that Maemo 5 exposed such a state in the UI is not an argument > to keep doing it. I asked this before, what are we suppose to be doing > when we get signaled suspended? User, as well as intelligent (connectivity-aware) applications, need to know about this so that they understand why "Internet" is momentarily broken. It's as simple as that. Oh we could also use the network device carrier flag, and then use Netlink (and we probably should do that too), but we all know how horrible Netlink is from userland. (...) > This is for ConnMan or similar to figure out. And we can always count > via netfilter or some other facility. Counting inside oFono makes no > sense. However we could send out a statistics signal before taking the > interface down if it would be really needed. Making it part of the > properties and having to poll for it is wrong. This has legal(ish) implications related to charging. Skipping this is not exactly an option (for a device vendor). I actually agree that this is ugly in some ways. In theory, I don't really care if Ofono or the over-lying connection manager takes care of it. *But* we even need to collect statistics for contexts not handled in Ofono (e.g. Windows PC tethering). And I doubt that Connman would be able to do that properly. It's ugly and annoying, but we have to suck it up. >> As I said, I think that the differences between this proposal and mine >> are mostly philosophical -- should the context data be stored in Ofono >> or in the upper layers of the stack? And should Ofono set the policies >> (for instance the roaming case) or just act as a low-level interface >> to the GPRS functionality? > > While oFono is sort of low-level, it is not that low-level. If it would > we could expose the native AT commands. So in summary the PDP context > are stored persistently in oFono. Like BlueZ remember paired devices. I fail to see how providing a direct low-level interface would prevent us from providing _also_ a higher-level interface. The later can handle provisioning and data persistence. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
2009/9/2 Marcel Holtmann : > Powered = on and RoamingAllowed = yes and Roaming = true will lead to > auto-attach. > > Powered = on and RoamingAllowed = no and Roaming = true will lead to > detach. > > Powered = on and Roaming = false will lead to auto-attach. > > Powered = off will lead to detach. Why is auto-attach dependent on roaming? > We are not going to expose Attach() or Detach() method. As explained > there are global anyway and so pointless to expose. This can be handled > in the background without bothering the higher level application with > these details. AFAIK, attach status of GPRS has both regulatory aspects to consider (some operators require always attached vs. some prohibit it) as well as power consumption issues (auto-attach might draw more power than on-demand, although there's an inverse effect on latency). These are issues you need to take into account, and higher layers in the stack definitely *need* to be aware of as well. Also, I don' t think oFono is the correct place for these decisions -> better expose a necessary API and let upper layers deal with it. In general, I appreciate the attempt to hide ugly details from applications, but unfortunately some things can't well be hidden. Another unrelated, but similar issue is network scanning. It just isn't going to work without us exposing it in the D-Bus API explicitly. The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Now, there is no way we can have GPRS suspend without warning just because the stack deems it necessary to scan for networks. Again the intention is good, but the end result not so good. I don't want to start patching oFono to support this type of basic stuff. >> In my proposal the "Status" variable was a three-state variable, >> having the states "attached", "detached" and "suspended". "Suspended" >> was specified to mean that the GPRS was attached, but temporarily not >> available (for instance because of a 2G phone call or temporary loss >> of cellular connectivity). In the IRC discussion someone said that >> this property would not be part of Denis's API because the tri-state >> variables were bad and the "suspended" status was not supported by >> spec 27.007. However, the problem is that Maemo 5 already has UI >> support for indicating that the connection is suspended, and that >> makes it harder to drop the feature. Could the "suspended" status enum >> still be left there, and just have the modems that don't support the >> feature to never go to "suspended" mode? > > I am still not seeing the point in what suspended will do for us and the > UI. And that Maemo 5 exposed such a state in the UI is not an argument > to keep doing it. I asked this before, what are we suppose to be doing > when we get signaled suspended? You will find that practically every Nokia phone behaves this way, i.e., you make a call in 2G, and the UI will inform you that GPRS is suspended while on call. >> Still one difference to my proposal was the dropping of the TX and RX >> byte counts, and the explanation that those statistics would be >> handled by the upper layers by reading the values from the network >> interface. I mentioned the problem where the connection was terminated >> by the network and the network interface was brought down before the >> upper layer had a chance to read the values. After giving the matter >> some thought, I still feel that for this reason the modem driver would >> need to get the TX/RX data and send it to the upper levels, if at all >> possible. Since many operators charge by the amount of data >> transferred, not losing the TX/RX data is quite crucial. At least >> Nokia phones have a GPRS data counter feature, that is supposed to >> show the transferred data. This said, I know that not all modem >> drivers can get the data from a connection that has been terminated by >> the network, but that does not mean that the modem drivers that can >> get the data should just discard it. > > This is for ConnMan or similar to figure out. And we can always count > via netfilter or some other facility. Counting inside oFono makes no > sense. However we could send out a statistics signal before taking the > interface down if it would be really needed. Making it part of the > properties and having to poll for it is wrong. I believe emitting a signal was Ismo's original proposal. > While oFono is sort of low-level, it is not that low-level. If it would > we could expose the native AT commands. So in summary the PDP context > are stored persistently in oFono. Like BlueZ remember paired devices. > > And for data roaming, we make it as simple as allowed = yes/no. This is > all the upper layer need to configure. > > Not exposing method for attach/detach is a logical consequence as > explained above. It is a global per modem detail and thus there is not
Re: GPRS support for Ofono
Hi Ismo, > > of this discussion. I'd like all interested to comment. What needs > > improvement? What is missing? What should be removed? > > Here are some comments. Some of the comments were already present in > the IRC discussion, but I'll repeat them here anyway. First of all, > the both Denis's proposal and mine look quite much the same -- the > basic objects are the GPRS manager and the PDP contexts, and they > offer quite the same functionality. Please correct me if I understood > some parts of Denis's proposal incorrectly. The big differences > between the API proposals are the creation and connecting of the > contexts and the handling of the attached/detached state. I'll try to > address the both issues below. > > In this proposal the contexts PDP contexts are persistent on the > device, meaning that they stay there also when Ofono is shut down. The > idea is that the contexts are made to Ofono by the GPRS provisioning > programs or by the UI, and then ConnMan or another upper layer needs > just to activate the context to actually do the connection. In my > proposal I thought that the higher layer components would keep track > of the access points and call the Connect() method with the suitable > connection parameters. > > This is a philosophical difference from the provisioning point of > view. An operator will likely support multiple configured access > points, and the provisioning program should know their purpose from > the configuration file (internet/MMS/WAP/...). This metadata is not > there in the Ofono context, meaning that the provisioning program > needs to store somewhere else the mapping between Ofono context object > paths and the neccessary metadata. This begs the question: why not > store all connection data (APN, authentication data, other metadata) > to this external store in the first place? I mentioned that already. We do wanna store something like Type that says internet, mms, wap etc. The only comment here was that for network initiated context we have no idea of its intent. > The attachment to the GPRS network in this proposal is bit vague. To > my understanding, to attach the GPRS you need to set "Powered" > property on and "RoamingAllowed" on. To detach you need to set the > "Powered" property off. Since attaching can take a long time (or > fail), does this mean that the attach errors are handled in the > "Powered" property setter callback? Or what happens when (during > roaming) the "Powered" is already on and the user puts the > "RoamingAllowed" on -- where are the attach errors handled? I kind of > think that it might be a better idea to just expose the GPRS > registration status and the attach status, and let a higher level > component explicitly set the attach/detach with either a readwrite > property or Attach() and Detach() methods. Powered = on and RoamingAllowed = yes and Roaming = true will lead to auto-attach. Powered = on and RoamingAllowed = no and Roaming = true will lead to detach. Powered = on and Roaming = false will lead to auto-attach. Powered = off will lead to detach. We are not going to expose Attach() or Detach() method. As explained there are global anyway and so pointless to expose. This can be handled in the background without bothering the higher level application with these details. > In my proposal the "Status" variable was a three-state variable, > having the states "attached", "detached" and "suspended". "Suspended" > was specified to mean that the GPRS was attached, but temporarily not > available (for instance because of a 2G phone call or temporary loss > of cellular connectivity). In the IRC discussion someone said that > this property would not be part of Denis's API because the tri-state > variables were bad and the "suspended" status was not supported by > spec 27.007. However, the problem is that Maemo 5 already has UI > support for indicating that the connection is suspended, and that > makes it harder to drop the feature. Could the "suspended" status enum > still be left there, and just have the modems that don't support the > feature to never go to "suspended" mode? I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? > Still one difference to my proposal was the dropping of the TX and RX > byte counts, and the explanation that those statistics would be > handled by the upper layers by reading the values from the network > interface. I mentioned the problem where the connection was terminated > by the network and the network interface was brought down before the > upper layer had a chance to read the values. After giving the matter > some thought, I still feel that for this reason the modem driver would > need to get the TX/RX data and send it to the upper levels, if at all > possible. Since many operators charge by the amou
Re: GPRS support for Ofono
On Wed, Sep 2, 2009 at 12:36 AM, Denis Kenzior wrote: > of this discussion. I'd like all interested to comment. What needs > improvement? What is missing? What should be removed? Here are some comments. Some of the comments were already present in the IRC discussion, but I'll repeat them here anyway. First of all, the both Denis's proposal and mine look quite much the same -- the basic objects are the GPRS manager and the PDP contexts, and they offer quite the same functionality. Please correct me if I understood some parts of Denis's proposal incorrectly. The big differences between the API proposals are the creation and connecting of the contexts and the handling of the attached/detached state. I'll try to address the both issues below. In this proposal the contexts PDP contexts are persistent on the device, meaning that they stay there also when Ofono is shut down. The idea is that the contexts are made to Ofono by the GPRS provisioning programs or by the UI, and then ConnMan or another upper layer needs just to activate the context to actually do the connection. In my proposal I thought that the higher layer components would keep track of the access points and call the Connect() method with the suitable connection parameters. This is a philosophical difference from the provisioning point of view. An operator will likely support multiple configured access points, and the provisioning program should know their purpose from the configuration file (internet/MMS/WAP/...). This metadata is not there in the Ofono context, meaning that the provisioning program needs to store somewhere else the mapping between Ofono context object paths and the neccessary metadata. This begs the question: why not store all connection data (APN, authentication data, other metadata) to this external store in the first place? The attachment to the GPRS network in this proposal is bit vague. To my understanding, to attach the GPRS you need to set "Powered" property on and "RoamingAllowed" on. To detach you need to set the "Powered" property off. Since attaching can take a long time (or fail), does this mean that the attach errors are handled in the "Powered" property setter callback? Or what happens when (during roaming) the "Powered" is already on and the user puts the "RoamingAllowed" on -- where are the attach errors handled? I kind of think that it might be a better idea to just expose the GPRS registration status and the attach status, and let a higher level component explicitly set the attach/detach with either a readwrite property or Attach() and Detach() methods. In my proposal the "Status" variable was a three-state variable, having the states "attached", "detached" and "suspended". "Suspended" was specified to mean that the GPRS was attached, but temporarily not available (for instance because of a 2G phone call or temporary loss of cellular connectivity). In the IRC discussion someone said that this property would not be part of Denis's API because the tri-state variables were bad and the "suspended" status was not supported by spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the "suspended" status enum still be left there, and just have the modems that don't support the feature to never go to "suspended" mode? Still one difference to my proposal was the dropping of the TX and RX byte counts, and the explanation that those statistics would be handled by the upper layers by reading the values from the network interface. I mentioned the problem where the connection was terminated by the network and the network interface was brought down before the upper layer had a chance to read the values. After giving the matter some thought, I still feel that for this reason the modem driver would need to get the TX/RX data and send it to the upper levels, if at all possible. Since many operators charge by the amount of data transferred, not losing the TX/RX data is quite crucial. At least Nokia phones have a GPRS data counter feature, that is supposed to show the transferred data. This said, I know that not all modem drivers can get the data from a connection that has been terminated by the network, but that does not mean that the modem drivers that can get the data should just discard it. Btw, is the context API missing the PDP type (IPv4 or IPv6)? As I said, I think that the differences between this proposal and mine are mostly philosophical -- should the context data be stored in Ofono or in the upper layers of the stack? And should Ofono set the policies (for instance the roaming case) or just act as a low-level interface to the GPRS functionality? By looking at Denis's proposal it is easy to see that my proposal wasn't perfect either. ;-) At least the GPRS registration state and possibly other properties need to be added to the D-Bus interface, and the API also needs to be made more future-pro
Re: GPRS support for Ofono
On Wed, 02 Sep 2009 04:03:05 -0700, Marcel Holtmann wrote: >> And this generally applies to services that operators have decided to >> run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC) >> and others. For example, Elisa in Finland seems to be running their >> MMSC behind an "mms" APN, with public IP address space, but firewalled >> from the rest of the Internet. oFono should isolate such an access >> from the rest of the system, since only the MMS client would know how >> to work with it properly. > > if they are doing something nasty like that, then the only real solution > is network namespaces. This means we can just bring the interface up and > then have to give all networking details via D-Bus properties. Yes. That's what I was saying, or at least trying to say. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, > >> personally I don't care who finally sets the IP for the interface. It > >> really just makes no difference. What problem do you see if oFono would > >> set the IP address on that newly created interface that is up and > >> running now? > > > > Then the application cannot influence the way it's done. That's the whole > > point. Maybe I want to migrate the interface in a new namespace. For that, > > it must (1) create the interface, (2) migrate it, (3) configure it, in that > > order. So Ofono cannot do (3) if it cannot do (2), and it certainly should > > not do (2) by itself. So it has to stick to (1). > > And this generally applies to services that operators have decided to > run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC) > and others. For example, Elisa in Finland seems to be running their > MMSC behind an "mms" APN, with public IP address space, but firewalled > from the rest of the Internet. oFono should isolate such an access > from the rest of the system, since only the MMS client would know how > to work with it properly. if they are doing something nasty like that, then the only real solution is network namespaces. This means we can just bring the interface up and then have to give all networking details via D-Bus properties. Actually we might should not even bring the network interface up, but it might be tricky with PPP or the HSO point-to-point stuff. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
2009/9/2 Rémi Denis-Courmont : >> personally I don't care who finally sets the IP for the interface. It >> really just makes no difference. What problem do you see if oFono would >> set the IP address on that newly created interface that is up and >> running now? > > Then the application cannot influence the way it's done. That's the whole > point. Maybe I want to migrate the interface in a new namespace. For that, > it must (1) create the interface, (2) migrate it, (3) configure it, in that > order. So Ofono cannot do (3) if it cannot do (2), and it certainly should > not do (2) by itself. So it has to stick to (1). And this generally applies to services that operators have decided to run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC) and others. For example, Elisa in Finland seems to be running their MMSC behind an "mms" APN, with public IP address space, but firewalled from the rest of the Internet. oFono should isolate such an access from the rest of the system, since only the MMS client would know how to work with it properly. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Wed, 02 Sep 2009 02:16:40 -0700, Marcel Holtmann wrote: > Hi Remi, > >> > Our current assumption is that the basic setup of IP address, netmask >> > and broadcast are done by oFono. Only routing and DNS are up to other >> > programs like ConnMan for example. >> >> WHAAT? No way. There is just no way. >> >> We need to support letting the calling program configure the routing >> parameters manually. For instance, if we want to connect to multiple >> primary access points, it simply won't work if Ofono configures > everything. >> Instead, we need to either setup source routing or separate network >> name-spaces. Ofono does not know what the caller intends to do with the > APN >> (and should not need to), so it cannot configure IP parameters. Besides, > it >> makes very little if any sense to configure IP parameters but not DNS. > > personally I don't care who finally sets the IP for the interface. It > really just makes no difference. What problem do you see if oFono would > set the IP address on that newly created interface that is up and > running now? Then the application cannot influence the way it's done. That's the whole point. Maybe I want to migrate the interface in a new namespace. For that, it must (1) create the interface, (2) migrate it, (3) configure it, in that order. So Ofono cannot do (3) if it cannot do (2), and it certainly should not do (2) by itself. So it has to stick to (1). -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, > > Our current assumption is that the basic setup of IP address, netmask > > and broadcast are done by oFono. Only routing and DNS are up to other > > programs like ConnMan for example. > > WHAAT? No way. There is just no way. > > We need to support letting the calling program configure the routing > parameters manually. For instance, if we want to connect to multiple > primary access points, it simply won't work if Ofono configures everything. > Instead, we need to either setup source routing or separate network > name-spaces. Ofono does not know what the caller intends to do with the APN > (and should not need to), so it cannot configure IP parameters. Besides, it > makes very little if any sense to configure IP parameters but not DNS. personally I don't care who finally sets the IP for the interface. It really just makes no difference. What problem do you see if oFono would set the IP address on that newly created interface that is up and running now? My point is that gateway and DNS is out of the question for oFono. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Tue, 01 Sep 2009 15:42:40 -0700, Marcel Holtmann wrote: > Our current assumption is that the basic setup of IP address, netmask > and broadcast are done by oFono. Only routing and DNS are up to other > programs like ConnMan for example. WHAAT? No way. There is just no way. We need to support letting the calling program configure the routing parameters manually. For instance, if we want to connect to multiple primary access points, it simply won't work if Ofono configures everything. Instead, we need to either setup source routing or separate network name-spaces. Ofono does not know what the caller intends to do with the APN (and should not need to), so it cannot configure IP parameters. Besides, it makes very little if any sense to configure IP parameters but not DNS. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Marcel,
> > Service org.ofono
> > Interface org.ofono.DataConnectionManager
>
> I think this should be GPRSManager or something to clearly separate
> between GRPS connections and actual data connection,
Two reasons for this:
- Purpose of DataConnectionManager is easier to understand for people
new to
GSM. Whereas GPRSManager really doesn't tell them anything. Everywhere else
we tend to use more easily understood terminology than what is used in the
specifications.
- GPRS is not easily Carmel-cased. E.g. we'd have to name it
GprsManager.
> > object RemoveContext()
> >
> > Removes a primary context. All secondary contexts, if
> > any, associated with the primary context are also
> > removed.
>
> I assume this is void RemoveContext(object context)
You're absolutely correct.
> > Properties array{object} PrimaryContexts [readonly]
> >
> > List of all primary contexts objects.
>
> Calling this just Contexts seems to more reasonable. See comment about
> interface name below.
That sounds fine to me.
> > Primary Data Context hierarchy
> > =
> >
> > Service org.ofono
> > Interface org.ofono.PrimaryDataContext
>
> I would prefer if we just call this GRPSContext and explain that this is
> for the primary context. The confusion between primary context and
> secondary context is some GSM specific non-sense.
Should we just simply name this 'Context' and name the secondary pdp context
'SubContext'?
> > array{string} DomainNameServers [readonly, optional]
> >
> > Holds the list of domain name servers for this
> > context.
>
> What about the gateway value. In theory we can just route it to the
> interface, but if the device fakes a real Ethernet interface and the
> gateway is in a different subnet we need a proper host route first.
Yes, this one needs to be added. Good catch.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Denis,
> So as it happens I had also been brainstorming a GPRS API for the last
> several
> days. And somewhat spontaneously a GPRS api discussion happened on IRC
> between myself, Marcel and Ismo. The following GPRS API proposal is a result
> of this discussion. I'd like all interested to comment. What needs
> improvement? What is missing? What should be removed?
>
> Please note that Secondary PDP contexts, Traffic Filters and Network
> Activated
> (Incoming) PDP contexts are not covered in this proposal. These features are
> not commonly used and none of us have real experience with them yet.
> However,
> we considered these features and have left room in the APIs for further
> expansion.
>
> Data Connection Manager hierarchy
> =
>
> Service org.ofono
> Interface org.ofono.DataConnectionManager
I think this should be GPRSManager or something to clearly separate
between GRPS connections and actual data connection,
> Object path [variable]
>
> Methods dict GetProperties()
>
> Returns all global system properties. See the
> properties section for available properties.
>
> Possible Errors: [service].Error.InvalidArguments
>
> void SetProperty(string property, variant value)
>
> Sets the property to a desired value
>
> Possible Errors: [service].Error.InvalidArguments
>[service].Error.InvalidFormat
>[service].Error.Failed
>
> void DeactivateAll()
>
> Deactivates all active contexts.
>
> object CreateContext()
>
> Creates a new Primary context. Returns the object
> path of the created context.
>
> object RemoveContext()
>
> Removes a primary context. All secondary contexts, if
> any, associated with the primary context are also
> removed.
I assume this is void RemoveContext(object context)
> Signals PropertyChanged(string property, variant value)
>
> This signal indicates a changed value of the given
> property.
>
> Propertiesarray{object} PrimaryContexts [readonly]
>
> List of all primary contexts objects.
Calling this just Contexts seems to more reasonable. See comment about
interface name below.
> boolean Attached [readonly]
>
> Contains whether the Packet Radio Service is attached.
> The attach state might change dynamically based on
> availability of network resources. If this value
> changes to false, the user can assume that all
> contexts have been deactivated.
>
> If the modem is detached, certain features will not
> be available, e.g. receiving SMS over packet radio
> or network initiated PDP activation.
>
> boolean RoamingAllowed [readwrite]
>
> Contains whether data roaming is allowed. In the off
> setting, if the packet radio registration state
> indicates that the modem is roaming, oFono will
> automatically detach and no further connection
> establishment will be possible.
>
> boolean Powered [readwrite]
>
> Controls whether packet radio use is allowed. Setting
> this value to off detaches the modem from the
> Packet Domain network.
>
> string Status [readonly]
>
> The current packet radio registration status of a modem.
>
> The possible values are:
> "unregistered" Not registered to any network
> "registered"Registered to home network
> "searching" Not registered, but searching
> "denied"Registration has been denied
> "unknown" Status is unknown
> "roaming" Registered, but roaming
>
> uint16 LocationAreaCode [readonly, optional]
>
> Contains the current location area code.
>
> uint32 CellId [readonly, optional]
>
> Contains the current network cell id.
>
> string Technology [readonly, optional]
>
> Contains the technology of the current network.
>
> The possible values are: "GSM", "GSMCompact", "UTRAN",
>
Re: GPRS support for Ofono
Everyone,
So as it happens I had also been brainstorming a GPRS API for the last several
days. And somewhat spontaneously a GPRS api discussion happened on IRC
between myself, Marcel and Ismo. The following GPRS API proposal is a result
of this discussion. I'd like all interested to comment. What needs
improvement? What is missing? What should be removed?
Please note that Secondary PDP contexts, Traffic Filters and Network Activated
(Incoming) PDP contexts are not covered in this proposal. These features are
not commonly used and none of us have real experience with them yet. However,
we considered these features and have left room in the APIs for further
expansion.
Data Connection Manager hierarchy
=
Service org.ofono
Interface org.ofono.DataConnectionManager
Object path [variable]
Methods dict GetProperties()
Returns all global system properties. See the
properties section for available properties.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
void DeactivateAll()
Deactivates all active contexts.
object CreateContext()
Creates a new Primary context. Returns the object
path of the created context.
object RemoveContext()
Removes a primary context. All secondary contexts, if
any, associated with the primary context are also
removed.
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Properties array{object} PrimaryContexts [readonly]
List of all primary contexts objects.
boolean Attached [readonly]
Contains whether the Packet Radio Service is attached.
The attach state might change dynamically based on
availability of network resources. If this value
changes to false, the user can assume that all
contexts have been deactivated.
If the modem is detached, certain features will not
be available, e.g. receiving SMS over packet radio
or network initiated PDP activation.
boolean RoamingAllowed [readwrite]
Contains whether data roaming is allowed. In the off
setting, if the packet radio registration state
indicates that the modem is roaming, oFono will
automatically detach and no further connection
establishment will be possible.
boolean Powered [readwrite]
Controls whether packet radio use is allowed. Setting
this value to off detaches the modem from the
Packet Domain network.
string Status [readonly]
The current packet radio registration status of a modem.
The possible values are:
"unregistered" Not registered to any network
"registered"Registered to home network
"searching" Not registered, but searching
"denied"Registration has been denied
"unknown" Status is unknown
"roaming" Registered, but roaming
uint16 LocationAreaCode [readonly, optional]
Contains the current location area code.
uint32 CellId [readonly, optional]
Contains the current network cell id.
string Technology [readonly, optional]
Contains the technology of the current network.
The possible values are: "GSM", "GSMCompact", "UTRAN",
"GSM+EGPS", "UTRAN+HSDPA",
"UTRAN+HSUPA",
"UTRAN+HSDPA+HSUPA",
"E-UTRAN"
Primary Data Context hierarchy
=
Service org.ofono
Interface org.ofono.PrimaryDataContext
Object path [variable]
RE: GPRS support for Ofono
On Tue, Sep 01, 2009 at 15:17:36, Jean-Christian de Rivaz wrote: > Thanks for the explanation. I will start learning how phonet works. > But I expect there exists a PPP stack somewhere in phonet because the > modem I use don't have one. And I don't think it's possible to have a > IP link over GPRS without the PPP protocol between them. On most modern modems there is no need to have a PPP link between the Application Processor (AP) and the modem. They will often be able to transmit IP traffic directly to the AP. Hence there is no PPP stack in phonet. If your modem does not support raw IP messaging (or any other datagram service) to the AP you will probably be stuck with good old PPP. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le mardi 1 septembre 2009 23:17:36 Jean-Christian de Rivaz, vous avez écrit : > Thanks for the explanation. I will start learning how phonet works. But > I expect there exists a PPP stack somewhere in phonet because the modem > I use don't have one. ISI modems have a PPP "server-side" implementation to handle USB CDC ACM and BlueTooth DUN. But there is only one instance per modem, so we reserve it for the dumb Windows PC that we may be connected to ;) > And I don't think it's possible to have a IP link > over GPRS without the PPP protocol between them. It might be possible in the standard, but I have not found any network offering such a PP over GPRS data service. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Rémi Denis-Courmont a écrit : Le mardi 1 septembre 2009 22:02:43 Jean-Christian de Rivaz, vous avez écrit : With GPRS support, Ofono become very interesting! I failed to understand how the "isi_gprs" code in your patch communicate with a PPP stack. That would be because it does NOT use a PPP stack. ISI modems have their own IP path using a dedicated kernel driver (net/phonet/pep-gprs.c in Linux 2.6.28 amd later). There is no point in using the PPP line discipline. Thanks for the explanation. I will start learning how phonet works. But I expect there exists a PPP stack somewhere in phonet because the modem I use don't have one. And I don't think it's possible to have a IP link over GPRS without the PPP protocol between them. Jean-Christian de Rivaz ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
On Tue, Sep 01, 2009 at 14:02:43, Jean-Christian de Rivaz wrote: > I failed to understand how the "isi_gprs" code in your patch > communicate with a PPP stack. For example, I currently use a project > where the APN is configured and a connection open with it. Then a pppd > process is started to establish the IP link. It seem that you make > this in a other (and certainly > better) way, but I missed the big picture. The best way to do this is without PPP and this is probably what Ismo is doing. You would just create a new net_device like "eth0" and hide all the ISI and cellular messaging behind that interface providing a clean IP network device. Best regards, Mikkel Christensen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le mardi 1 septembre 2009 22:02:43 Jean-Christian de Rivaz, vous avez écrit : > With GPRS support, Ofono become very interesting! > > I failed to understand how the "isi_gprs" code in your patch communicate > with a PPP stack. That would be because it does NOT use a PPP stack. ISI modems have their own IP path using a dedicated kernel driver (net/phonet/pep-gprs.c in Linux 2.6.28 amd later). There is no point in using the PPP line discipline. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Ismo Puustinen a écrit : I started working on Ofono GPRS support. Hello, With GPRS support, Ofono become very interesting! I failed to understand how the "isi_gprs" code in your patch communicate with a PPP stack. For example, I currently use a project where the APN is configured and a connection open with it. Then a pppd process is started to establish the IP link. It seem that you make this in a other (and certainly better) way, but I missed the big picture. Best Regards, Jean-Christian de Rivaz ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
