Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Pekka. Do you think we will ever have more than one IMS ConnectionContext pr SIM? If not not we could probably keep the PcscfAddresses in this IMS API (see object-path proposal below). Unfortunately, yes. Could you please elaborate on this. Do you really foresee a scenario where an operator will provide more than one IMS network? Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Sjur,
doc/ims-api.txt | 119
+++
1 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 doc/ims-api.txt
+Propertiesboolean ImsVoiceRegistered [readwrite, optional]
+
+Inform modem's radio stack that the IMS application
+has registered for Voice over IMS. This impacts
+UE Mode of operation and the ISR feature in the
+radio stack. Related AT command: AT+EISR
+
+boolean ImsSmsRegistered [readwrite, optional]
+
+Inform modem's radio stack that the IMS application
+has registered for SMS over IMS. This impacts
+UE Mode of operation and the ISR feature in the
+radio stack. Related AT command: AT+EISR
+
+boolean ImsVoiceOverPs [readonly, optional]
+
+IMS voice is enabled by network
+Related AT command: AT+CIREP.
+
Which specification details this AT command, searched in 27.007 rel 10, but it
is
not available there.
Isn't ISR a property by default a UE should have when it is registered to LTE?.
23.401 says ISR support is mandatory for E-UTRAN UEs that support GERAN and/or
UTRAN and optional for the network.
i don't think this setting should affect ISR behavior.
+string PrivateImsIdentity [readonly, optional]
+
+Identity used for IMS registration.
+Available if present on the ISIM.
+
+string PublicImsIdentity [readonly, optional]
+
+Identity used for IMS registration.
+Available if present on the ISIM.
+
+string HomeDomainName[readonly, optional]
+
+Identity used for IMS registration.
+Available if present on the ISIM.
+
Will these not be known to the user?
When does this interface becomes alive (org.ofono.ims)? post_sim or post_online?
+string ImsToCsHandoverStatus [readonly, optional]
+
+Indicate the handover progress status during a CS
+fallback procedure. This property will only be present
+when in LTE coverage. The possible values are:
+none, started,complete, failure.
+Related AT URC: +CIREP
+
Again which specification details these AT commands?. Do we need a property
like this to show the CSFB?
why can't we...
while in LTE:
oFono has network registration, connection manager, SIM and LTE
specific interfaces
while in CSFB :
oFono has all other interfaces too.
+array{string} PcscfAddresses[readonly]
+
+Domain Name or IP Address of the P-CSCF servers.
+(SIP Proxy).
+
This should be optional property based on the service table information.
+array{dict,array{dict}} QosFilters [readonly, optional]
+
+Information about the QoSes and associated Packet
+Filters for the Default PDN and it's dedicated bearers.
+It is organized as a list of QoS definitions with
+a list of corresponding packet filters.
+
+uint8 QoSClassIdentifier [readonly]
+The numeric parameter that specifying
+the class of QoS. (3GPP TS 23.203 [85])
+0QCI is selected by network
+[1 – 4] guaranteed bit rate
+[5 – 9] non-guaranteed bit rate
+
+uint16 UplinkRate [readonly, optional]
+Guaranteed Uplink Bit-rate in kb/sec.
+
+uint16 DownlinkRate [readonly, optional]
+Guaranteed Downlink Bit-rate in kb/sec.
+
+For each QoS defined there may be a list of Packet
+Filters. Each Packet Filter is a dictionary defining
+the filter. An empty Packet Filter represents the
+default filter (Default PDN connection).
+
+string Direction [readonly]
+uplink, downlink, bidirectional
+
+uint8 ProtocolNumber [readonly]
+IP protocol number (0-256)
+
+string PeerAddress [readonly]
+The remote peer's IP address.
+
+uint16 PeerPortMin [readonly]
+Remote peer's port number min. value
+
+uint16 PeerPortMax [readonly]
+Remote peer's port number max. value
+
+uint16 LocalePortMin [readonly]
+The local port number min. value
+
+uint16 LocalPortMax [readonly]
+The local port number max. value
Do we really need this?. What is the real usage of this information?.
In 27.007 there are few AT commands for TFT, and are not used, may be because
no body (operator) supports this.
In LTE will this be going to be different?
regards
Arun
___
ofono mailing list
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Arun, 2011/1/28 Arun Ravindran ext-arun.1.ravind...@nokia.com: + boolean ImsVoiceOverPs [readonly, optional] + + IMS voice is enabled by network + Related AT command: AT+CIREP. + Which specification details this AT command, searched in 27.007 rel 10, but it is not available there. According to the 27.007 CRs, it should be in 10.0.0: http://www.3gpp.org/ftp/specs/html-info/27007-CRs.htm My copy is 10.2., and it has CIREP along with +CIREPI,+ CIRPEH and +CISRVCC, Isn't ISR a property by default a UE should have when it is registered to LTE?. 23.401 says ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. i don't think this setting should affect ISR behavior. The ISR means that device is registered to both 2G/3G and LTE. It might receive pagings from both of these radio networks. However, the network needs to know if the currently available radio network supports PS voice or not, so the device has to update its state when changing between LTE radio supporting PS voice and other radio not supporting it. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Rémi, - The QoS information is presented as an array of QoS settings with an associated list IP Packet Filters. Only the QoS data for connection context of type IMS will be reported. The assumption is that QoS is only going to be used by IMS applications. Initially I was planning to put this in the connman-api.txt, but based on feedback from Denis in the Paris workshop I have moved this to the IMS API. If this assumption proves wrong QoS should be moved to ConnectionContext interface. What is this for? In my understanding, the LTE modem will do the classification on outgoing packets - not the application engine. Indeed, based on the proposed API, there is no way for the application engine to tag packet for the benefit of the modem... Yes, this is correct. The modem should take care of this. And we do not need to know anything about classification of incoming packets, other than which primary context they belong to. The point here is that the IMS application needs some information about the QoS it actually got from the network. Apparently IMS-app needs this for selecting appropriate codec-parameters to use. That's the only purpose of presenting this information. +Properties boolean ImsVoiceRegistered [readwrite, optional] + + Inform modem's radio stack that the IMS application + has registered for Voice over IMS. This impacts + UE Mode of operation and the ISR feature in the + radio stack. Related AT command: AT+EISR I suppose this should be similar to Modem.Lockdown: only one D-Bus client can set it (at a time), and it gets automatically cleared if said client dies. I assume you are right, but someone knowing more about the IMS application should answer on this Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Sjur, 2011/1/26 Sjur Brændeland sjurb...@gmail.com: Features: - The QoS information is presented as an array of QoS settings with an associated list IP Packet Filters. Only the QoS data for connection context of type IMS will be reported. The assumption is that QoS is only going to be used by IMS applications. Initially I was planning to put this in the connman-api.txt, but based on feedback from Denis in the Paris workshop I have moved this to the IMS API. If this assumption proves wrong QoS should be moved to ConnectionContext interface. The UE initiates the Default Bearer. In R8, the Network may then initiate a number of Dedicated Bearers. Each Dedicated Bearer will have a defined QoS. In order to route the IP traffic into the different Dedicated Bearers, a set of Packet Filters can be defined for each Dedicated Bearer. I think we need these in ConnectionContext, or perhaps a separate DedicatedContext interface would be better. The structure of QoS TFT Also the PcscfAddresses should be part of the Settings or Settings6 in ConnectionContext. - The UE-Mode of operation, is primarily triggered by IMS application registering to the RadioStack that it has registered on Voice and/or SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered. - SIM identities used for IMS registration such as: PrivateImsIdentity, PublicImsIdentity, HomeDomainName. These should be available from separate interface/object, one for each ISIM. Otherwise, this looks fine. Rémi and Marcel had some other concerns... -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Pekka,
Features:
- The QoS information is presented as an array of QoS settings with
an associated list IP Packet Filters. Only the QoS data for
connection context of type IMS will be reported.
The assumption is that QoS is only going to be used by IMS applications.
Initially I was planning to put this in the connman-api.txt, but based
on feedback from Denis in the Paris workshop I have moved this to the
IMS API. If this assumption proves wrong QoS should be moved to
ConnectionContext interface.
The UE initiates the Default Bearer. In R8, the Network may then
initiate a number of Dedicated Bearers. Each Dedicated Bearer will
have a defined QoS. In order to route the IP traffic into the
different Dedicated Bearers, a set of Packet Filters can be defined
for each Dedicated Bearer.
I think we need these in ConnectionContext, or perhaps a separate
DedicatedContext interface would be better.
Yes, as I mentioned earlier I considered this as well. But do you see other
scenarios than IMS where the NW will set up Dedicated Bearers?
Also the PcscfAddresses should be part of the Settings or Settings6
in ConnectionContext.
Do you think we will ever have more than one IMS ConnectionContext pr SIM?
If not not we could probably keep the PcscfAddresses in this IMS API (see
object-path proposal below).
- The UE-Mode of operation, is primarily triggered by IMS application
registering to the RadioStack that it has registered on Voice and/or
SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered.
- SIM identities used for IMS registration such as: PrivateImsIdentity,
PublicImsIdentity, HomeDomainName.
These should be available from separate interface/object, one for each ISIM.
I guess if you have more than one SIM, you would in fact have two
modem instances
and two instance of this API. In the next patch I should probably use
[{modem1},{modem2}...] as the
object-path of this IMS object.
Regards,
Sjur
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Sjur,
2011/1/27 Sjur Brændeland sjurb...@gmail.com:
I think we need these in ConnectionContext, or perhaps a separate
DedicatedContext interface would be better.
Yes, as I mentioned earlier I considered this as well. But do you see other
scenarios than IMS where the NW will set up Dedicated Bearers?
I have no idea. On the other hand, there should be a straightforward
way to correlate these and the context that uses them; retrieving them
from the context is such a straightforward way.
Also the PcscfAddresses should be part of the Settings or Settings6
in ConnectionContext.
Do you think we will ever have more than one IMS ConnectionContext pr SIM?
If not not we could probably keep the PcscfAddresses in this IMS API (see
object-path proposal below).
Unfortunately, yes.
- The UE-Mode of operation, is primarily triggered by IMS application
registering to the RadioStack that it has registered on Voice and/or
SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered.
- SIM identities used for IMS registration such as: PrivateImsIdentity,
PublicImsIdentity, HomeDomainName.
These should be available from separate interface/object, one for each ISIM.
I guess if you have more than one SIM, you would in fact have two
modem instances
and two instance of this API. In the next patch I should probably use
[{modem1},{modem2}...] as the
object-path of this IMS object.
ISIM is an application on SIM card (also known as UICC). There can be
multiple ISIMs on a single card but only a single USIM (3G SIM
application) or 2G SIM application.
--
Pekka.Pessi mail at nokia.com
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC] doc: Proposal for LTE/IMS API.
Hi Pekka, Sjur,
I think we need these in ConnectionContext, or perhaps a separate
DedicatedContext interface would be better. The structure of QoS TFT
Also the PcscfAddresses should be part of the Settings or Settings6
in ConnectionContext.
I prepared a patched in this way sometimes ago for the Dedicated Bearers maybe
it can help :
--
*** ofono-0.36/doc/connman-api.txt 2010-10-31 17:48:50.0 +0100
--- ofono-patched/doc/connman-api.txt 2010-12-09 17:44:32.694063480 +0100
***
*** 132,141
--- 132,163
[service].Error.NotAttached
[service].Error.AttachInProgress
+ array{object,dict} GetSecondarys()
+
+ Get array of secondary context objects and properties.
+
+ The method should only be call once per application.
+ Further changes shall be monitored via SecondaryAdded
+ SecondaryRemoved signals.
+
+
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
+
+ SecondaryAdded(object path, dict properties)
+
+ Signal that gets emitted when a new secondary context
has
+ been created. It contains the secondary context object
path
+ and its properties.
+
+ SecondaryRemoved(object path)
+
+ Signal that gets emitted when a secondary context has
been
+ removed. The object path of the secondary context is
only
+ included for reference. Its properties are no
+ longer accessible at this point.
Propertiesboolean Active [readwrite]
***
*** 239,241
--- 261,350
string MessageCenter [readwrite, MMS only]
Holds the MMSC setting.
+
+
+
+
+ Connection Secondary Context hierarchy
+ =
+ Service org.ofono
+ Interface org.ofono.SecondaryConnectionContext
+ Object path /modemX/contextX/secondaryY
+
+
+ Methods void Close()
+ Deactivate secondary context (dedicated bearer in LTE)
+
+ array{object,dict} GetTFTs()
+
+ Get array of TFT objects and properties.
+
+ The method should only be call once per application.
+ Further changes shall be monitored via TFTAdded
+ TFTRemoved signals.
+
+ Signals TFTAdded(object path, dict properties)
+
+ Signal that gets emitted when a new context has
+ been created. It contains the context object path
+ and its properties.
+
+ TFTRemoved(object path)
+
+ Signal that gets emitted when a context has been
+ removed. The object path of the context is only
+ included for reference. Its properties are no
+ longer accessible at this point.
+
+ TFT hierarchy
+ =
+ Service org.ofono
+ Interface org.ofono.TFT
+ Object path /modemX/contextX/secondaryY/TFTZ
+
+ Methods dict GetProperties()
+ Returns all properties for the context object.
+
+ 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
+
+ object GetSecondaryContext()
+
+ Returns the related Secondary(dedicated) context
+
+
+ Signals PropertyChanged(string property, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ Properties string DestinationAddress [read]
+
+ Holds the destination Address
+
+ string SubnetMask [read]
+
+ Holds the SbunetMask
+
+ integer DestinationPortRangeStart [read]
+
+ Holds the destination port range start
+
+ integer DestinationPortRangeEnd [read]
+
+
Re: [RFC] doc: Proposal for LTE/IMS API.
Hello,
On Wednesday 26 January 2011 16:59:03 ext Sjur Brændeland, you wrote:
Features:
- The QoS information is presented as an array of QoS settings with
an associated list IP Packet Filters. Only the QoS data for
connection context of type IMS will be reported.
The assumption is that QoS is only going to be used by IMS applications.
Initially I was planning to put this in the connman-api.txt, but based
on feedback from Denis in the Paris workshop I have moved this to the
IMS API. If this assumption proves wrong QoS should be moved to
ConnectionContext interface.
What is this for? In my understanding, the LTE modem will do the classification
on outgoing packets - not the application engine. Indeed, based on the
proposed API, there is no way for the application engine to tag packet for the
benefit of the modem...
And we do not need to know anything about classification of incoming packets,
other than which primary context they belong to.
(...)
+Properties boolean ImsVoiceRegistered [readwrite, optional]
+
+ Inform modem's radio stack that the IMS application
+ has registered for Voice over IMS. This impacts
+ UE Mode of operation and the ISR feature in the
+ radio stack. Related AT command: AT+EISR
I suppose this should be similar to Modem.Lockdown: only one D-Bus client can
set it (at a time), and it gets automatically cleared if said client dies.
+ boolean ImsSmsRegistered [readwrite, optional]
+
+ Inform modem's radio stack that the IMS application
+ has registered for SMS over IMS. This impacts
+ UE Mode of operation and the ISR feature in the
+ radio stack. Related AT command: AT+EISR
Ditto.
+ boolean ImsVoiceOverPs [readonly, optional]
+
+ IMS voice is enabled by network
+ Related AT command: AT+CIREP.
I guess the first two should not be settable if this one is false.
+ string PrivateImsIdentity [readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
+
+ string PublicImsIdentity [readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
+
+ string HomeDomainName[readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
+
+ string ImsToCsHandoverStatus [readonly, optional]
+
+ Indicate the handover progress status during a CS
+ fallback procedure. This property will only be present
+ when in LTE coverage. The possible values are:
+ none, started,complete, failure.
+ Related AT URC: +CIREP
+
+ array{string} PcscfAddresses[readonly]
+
+ Domain Name or IP Address of the P-CSCF servers.
+ (SIP Proxy).
+
+ array{dict,array{dict}} QosFilters [readonly, optional]
+
+ Information about the QoSes and associated Packet
+ Filters for the Default PDN and it's dedicated bearers.
+ It is organized as a list of QoS definitions with
+ a list of corresponding packet filters.
+
+ uint8 QoSClassIdentifier [readonly]
+ The numeric parameter that specifying
+ the class of QoS. (3GPP TS 23.203 [85])
+ 0 QCI is selected by network
+ [1 – 4] guaranteed bit rate
+ [5 – 9] non-guaranteed bit rate
+
+ uint16 UplinkRate [readonly, optional]
+ Guaranteed Uplink Bit-rate in kb/sec.
+
+ uint16 DownlinkRate [readonly, optional]
+ Guaranteed Downlink Bit-rate in kb/sec.
+
+ For each QoS defined there may be a list of Packet
+ Filters. Each Packet Filter is a dictionary defining
+ the filter. An empty Packet Filter represents the
+ default filter (Default PDN connection).
+
+ string Direction [readonly]
+ uplink, downlink, bidirectional
+
+ uint8 ProtocolNumber [readonly]
+ IP protocol number (0-256)
+
+ string PeerAddress [readonly]
+ The remote peer's IP
