[RFC] doc: Proposal for LTE/IMS API.

[RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 5948 bytes --]

From: Sjur Brændeland <sjur.brandeland@stericsson.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.

- 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.

- For SRVCC (IMS to CS handover) the property ImsToCsHandoverStatus
  is added for providing handover progress information. This property
  is currently a little futuristic, but is presented for completeness.

- ImsVoiceOverPs shows if Network supports IMS voice.
---

This is the initial RFC for the LTE/IMS API. Most of this (except
the QoS parts) has been presented in a worshop in Paris.Based on
input in the workshop I have created this new IMS API.

Feedback and comments are welcome :-)
I'm particularly interested to know if anything should be
removed (or added) from the QoS information. I would like to
see if we could do this any simpler.

Regards,
Sjur

 doc/ims-api.txt |  119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 119 insertions(+), 0 deletions(-)
 create mode 100644 doc/ims-api.txt

diff --git a/doc/ims-api.txt b/doc/ims-api.txt
new file mode 100644
index 0000000..865413f
--- /dev/null
+++ b/doc/ims-api.txt
@@ -0,0 +1,119 @@
+IMS hierarchy  [experimental]
+=============================
+
+Service		org.ofono
+Interface	org.ofono.Ims
+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
+
+Signals		PropertyChanged(string property, variant value)
+
+			This signal indicates a changed value of the given
+			property.
+
+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
+
+		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.
+
+		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 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
-- 
1.7.1

Re: [RFC] doc: Proposal for LTE/IMS API.

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 4518 bytes --]

	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 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


-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

Re: [RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

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

Re: [RFC] doc: Proposal for LTE/IMS API.

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3737 bytes --]

Hi Sjur,

>  doc/ims-api.txt |  119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 119 insertions(+), 0 deletions(-)
>  create mode 100644 doc/ims-api.txt
> 
> diff --git a/doc/ims-api.txt b/doc/ims-api.txt
> new file mode 100644
> index 0000000..865413f
> --- /dev/null
> +++ b/doc/ims-api.txt
> @@ -0,0 +1,119 @@
> +IMS hierarchy  [experimental]
> +=============================
> +
> +Service		org.ofono
> +Interface	org.ofono.Ims
> +Object path	[variable]

we are trying to not use abbreviations for the interface names. So maybe
something like org.ofono.MultimediaSubsystem would be better.

> +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
> +
> +Signals		PropertyChanged(string property, variant value)
> +
> +			This signal indicates a changed value of the given
> +			property.
> +
> +Properties	boolean ImsVoiceRegistered [readwrite, optional]

Since the interface name already contains the reference to IMS, we did
avoid to have namespacing as part of the property names. So in this case
using VoiceRegistered would be more correct.

> +			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]

We did try not to use SMS etc. So maybe MessagingRegistered would be
better.

> +
> +			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.
> +
> +		string  PrivateImsIdentity [readonly, optional]
> +
> +			Identity used for IMS registration.
> +			Available if present on the ISIM.

Same goes here, PrivateIdentify etc. I think you catch the drift.

> +
> +		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.

We really need to understand what the IMS application will need. If this
is about codecs or other things, then maybe oFono should give codec
advise directly. Proposals are welcome. Right now this looks like going
overboard.

Regards

Marcel

RE: [RFC] doc: Proposal for LTE/IMS API.

[Kai.Vehmanen]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Hi,

On 27 Jan 2011, Marcel Holtmann wrote:
>> +		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.
> 
> We really need to understand what the IMS application will need. If
> this is about codecs or other things, then maybe oFono should give codec
> advise directly. Proposals are welcome. Right now this looks like going
> overboard.

this is used e.g. for SDP preconditions mechanism used in IMS:
http://www.faqs.org/rfcs/rfc3312.html

The QoS is signalled on a per port/media basis, so relaying 
the packet-filters seems like a sane approach to me (cannot really
say the same about 3312, but that's a different thing ;P).

Re: [RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

Hi Kai,

>>> +            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.
>>
>> We really need to understand what the IMS application will need. If
>> this is about codecs or other things, then maybe oFono should give codec
>> advise directly. Proposals are welcome. Right now this looks like going
>> overboard.
>
> this is used e.g. for SDP preconditions mechanism used in IMS:
> http://www.faqs.org/rfcs/rfc3312.html
>
> The QoS is signalled on a per port/media basis, so relaying
> the packet-filters seems like a sane approach to me (cannot really
> say the same about 3312, but that's a different thing ;P).

OK, good to hear.

The 27007 spec specifies the following responses related to TFT/QoS:
+CGTFTRDP: <cid>,<packet filter identifier>,<evaluation precedence index>,
<source address and subnet mask>,<protocol number (ipv4) / next header (ipv6)>,
<destination port range>, <source port range>,<ipsec security
parameter index (spi)>,
<type of service (tos) (ipv4) and mask / traffic class (ipv6) and mask>,
<flow label (ipv6)>,<direction>,<NW packet filter Identifier>

+CGEQOSRDP: <cid>,<QCI>,[<DL_GBR>,<UL_GBR>],[<DL_MBR>,<UL_MBR>]

I tried to pick the minimal set of interesting parameters,
but I would really love some feedback on this from someone who knows
more about the IMS requirements here.

Regards,
Sjur

Re: [RFC] doc: Proposal for LTE/IMS API.

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

Hi Sjur,

2011/1/26 Sjur Brændeland <sjurbren@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

Re: [RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

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

RE: [RFC] doc: Proposal for LTE/IMS API.

[Soum, RedouaneX]

[-- Attachment #1: Type: text/plain, Size: 4612 bytes --]

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.000000000 +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.
  
  Properties	boolean 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]
+ 		
+ 			Holds the destination port range end
+ 		
+ 		integer SourcePortRangeStart [read]
+ 		
+ 			Holds the source port range start
+ 			
+ 		integer SourcePortRangeEnd [read]
+ 		
+ 			Holds the source port range end


Regards,
Redouane.
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC] doc: Proposal for LTE/IMS API.

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

Hi Sjur,

2011/1/27 Sjur Brændeland <sjurbren@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

RE: [RFC] doc: Proposal for LTE/IMS API.

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

Hi Sjur,

ofono-bounces(a)ofono.org wrote:
> 
> - SIM identities used for IMS registration such as:
>   PrivateImsIdentity, PublicImsIdentity, HomeDomainName.

Correct me if I'm wrong. Private Identity is the one used for registration, authorisation, administration and billing purposes whereas the Public Identity is the identity by which the other parties know the subscriber. Basically, Public Identity is not used for IMS registration.

> +		string  PrivateImsIdentity [readonly, optional]
> +
> +			Identity used for IMS registration.
> +			Available if present on the ISIM.
> +

May I know whats the use of making it available to the user?
EFimpi is a mandatory file on the ISIM, so it is available always if the ISIM is present in an UICC card.

> +		string  PublicImsIdentity [readonly, optional]
> +
> +			Identity used for IMS registration.
> +			Available if present on the ISIM.

There can be more than one public identity. And also public identity is not used for IMS registration. same as EFimpi, EFimpu is a mandatory file on the ISIM.

> +
> +		string  HomeDomainName[readonly, optional]
> +
> +			Identity used for IMS registration.
> +			Available if present on the ISIM.
> +

same as EFimpi and EFimpu, EFdomain is a mandatory file.
Correct me if I'm wrong. Domain name just indicates the home network of the subscriber.
Is it really used for registration?

> +		array{string}  PcscfAddresses[readonly]
> +
> +			Domain Name or IP Address of the P-CSCF servers.
> +			(SIP Proxy).

If I'm correct, this information also comes from the sim file EFp-cscf and it is optional.

Regards,
Jeevaka

Re: [RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

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

RE: [RFC] doc: Proposal for LTE/IMS API.

[Kjetil ASDAL]

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

Hi,

> ---------- Forwarded message ----------
> From:  <Jeevaka.Badrappan@elektrobit.com>
> Date: Fri, Jan 28, 2011 at 11:22 AM
> Subject: RE: [RFC] doc: Proposal for LTE/IMS API.
> To: ofono(a)ofono.org
> Cc: sjur.brandeland(a)stericsson.com
>
>
> Hi Sjur,
>
> ofono-bounces(a)ofono.org wrote:
> >
> > - SIM identities used for IMS registration such as:
> >   PrivateImsIdentity, PublicImsIdentity, HomeDomainName.
>
> Correct me if I'm wrong. Private Identity is the one used for
> registration, authorisation, administration and billing purposes
> whereas the Public Identity is the identity by which the other parties
> know the subscriber. Basically, Public Identity is not used for IMS
> registration.

The Private Identity is used to allow the UE access to the IMS network (for, 
as you say, the purpose of registration, authorization, administration and 
billing). 

The Public Identity is used to identify a specific IMS user (there may be more 
than one associated with one Private Identity). This information is conveyed to 
the IMS CN during registration so that the network can know what IMS users that 
are registered and available for service (e.g. a reception of a voice session).

As far as I can see, the Home Network Domain Name is also part of the SIP 
registration procedure.

>
> > +             string  PrivateImsIdentity [readonly, optional]
> > +
> > +                     Identity used for IMS registration.
> > +                     Available if present on the ISIM.
> > +
>
> May I know whats the use of making it available to the user?
> EFimpi is a mandatory file on the ISIM, so it is available always if
> the ISIM is present in an UICC card.
>
> > +             string  PublicImsIdentity [readonly, optional]
> > +
> > +                     Identity used for IMS registration.
> > +                     Available if present on the ISIM.
>
> There can be more than one public identity. And also public identity
> is not used for IMS registration. same as EFimpi, EFimpu is a
> mandatory file on the ISIM.
>
> > +
> > +             string  HomeDomainName[readonly, optional]
> > +
> > +                     Identity used for IMS registration.
> > +                     Available if present on the ISIM.
> > +
>
> same as EFimpi and EFimpu, EFdomain is a mandatory file.
> Correct me if I'm wrong. Domain name just indicates the home network
> of the subscriber.
> Is it really used for registration?
>
> > +             array{string}  PcscfAddresses[readonly]
> > +
> > +                     Domain Name or IP Address of the P-CSCF servers.
> > +                     (SIP Proxy).
>
> If I'm correct, this information also comes from the sim file EFp-cscf
> and it is optional.
>
> Regards,
> Jeevaka
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>

Regards,
Kjetil

RE: [RFC] doc: Proposal for LTE/IMS API.

[Kai.Vehmanen]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

Hi,

On 31 Jan 2011, Sjur Brændeland wrote:
>> Sjur Brændeland wrote:
>>> +        array{dict,array{dict}} QosFilters [readonly, optional]
>>> +
>>> +            Information about the QoSes and associated Packet
>>> +            Filters for the Default PDN and it's dedicated
> Arun Ravindran wrote:
>> 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.
>
> BTW, did you see the response from Kai earlier in this mail thread?
> [kai.vehmanen(a)nokia.com wrote:]
> >this is used e.g. for SDP preconditions mechanism used in IMS:
> >http://www.faqs.org/rfcs/rfc3312.html

just to add to this: some information about the traffic filters 
is most definitely needed (RFC3312 is needed to set up calls 
according to TS24.229 and e.g. GSMA IR.92 ([1] a profile using 24.229)).

So in short the idea is that phone should not start alerting
before it has got a confirmation it has a voice-ready data connection
set up (including QoS).

But as the modem is just a IP transport in this case and does not know 
which ports (nor even which protocols) are used for voice (and which media 
streams are used by the application), it is really hard to prune down 
the list of information provided via oFono with 'QosFilters'. In the 
end it's the application that needs to check all the IP flows needed
for the call are covered by sufficient QoS, before continuing the call 
establishment.

So I'm not sure what the strategy should be.. expose the full
27.007 set, expose list based on what the first modems implementing
the interface support, or prune the list based on some known application
(e.g. IR.92 profile of TS24.229), or something in between.
The oFono design principle of '4.2 Minimal & Complete' is not so easy
to apply when doing something new... ;)

[1] http://gsmworld.com/documents/IR9230.pdf

Re: [RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 5311 bytes --]

Hi Arun,

>>  +        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?

These are read from the ISIM, so I believe this should be available post_sim.

>>  +        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?

ImsToCsHandoverStatus is the progress notification of the actual
handover from LTE to CS,
I believe this information will be needed for setting up the CMT
device (CS Audio) and
knowing when to switch from IMS Audio to CS Audio streams.

> 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.

Yes, agree.
CSFB will look similar to the case where you loose your LTE coverage
and move to WCDMA/GSM. You will have the same oFono APIs available
in both cases, regardless of how the change was initiated.


>>  +        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 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?

In LTE the network will be responsible for setting up Dedicated
Bearers (Secondary PDPs).
And I believe the IMS application needs information about the
TFT/QoSes when setting up a call.

BTW, did you see the response from Kai earlier in this mail thread?
[kai.vehmanen(a)nokia.com wrote:]
>this is used e.g. for SDP preconditions mechanism used in IMS:
>http://www.faqs.org/rfcs/rfc3312.html
>The QoS is signalled on a per port/media basis, so relaying
>the packet-filters seems like a sane approach to me (cannot really
>say the same about 3312, but that's a different thing ;P).


Regards,
Sjur

Re: [RFC] doc: Proposal for LTE/IMS API.

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Hi Arun,

2011/1/28 Arun Ravindran <ext-arun.1.ravindran@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

Re: [RFC] doc: Proposal for LTE/IMS API.

[Arun Ravindran]

[-- Attachment #1: Type: text/plain, Size: 5280 bytes --]


Hi Sjur,

>  doc/ims-api.txt |  119
>  +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 files changed, 119 insertions(+), 0 deletions(-)
>   create mode 100644 doc/ims-api.txt
>
>
>  +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
>  +
>
>  +        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])
>  +                    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 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