doc: Proposal for LTE/IMS API.
Hi Sjur,
Quoted 20 lines
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
Quoted 6 lines
+
+ 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.
Quoted 16 lines
+ 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?
Quoted 8 lines
+ 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.
Quoted 5 lines
+ 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.
Quoted 37 lines
+ 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
+
Quoted 9 lines
+ 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
Hi Arun,
2011/1/28 Arun Ravindran <[email protected]>:
Quoted 8 lines
Quoted 5 lines
+ 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,
Quoted 4 lines
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.
Signature · 1 line
Pekka.Pessi mail at nokia.com
Hi Arun,
Quoted 16 lines
Quoted 7 lines
+ string PrivateImsIdentity [readonly, optional] +
+ Identity used for IMS registration.
+ Available if present on the ISIM. +
+ string PublicImsIdentity [readonly, optional] +Quoted 8 lines
+ 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. +
Quoted 3 lines
Will these not be known to the user?
When does this interface becomes alive (org.ofono.ims)?post_simorpost_online?
These are read from the ISIM, so I believe this should be available post_sim.
Quoted 11 lines
Quoted 8 lines
+ 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.
Quoted 8 lines
why can't we...
while in LTE:
oFono has network registration, connection manager, SIM and LTE specific interfaceswhile 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.
Quoted 47 lines
Quoted 37 lines
+ 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 +Quoted 9 lines
+ 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
Quoted 5 lines
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:]
Quoted 5 lines
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
Hi,
Quoted 5 lines · Sjur Brændeland
Quoted 5 lines
Quoted 4 lines · Sjur Brændeland
+ array{dict,array{dict}} QosFilters [readonly, optional] +
+ Information about the QoSes and associated Packet
+ Filters for the Default PDN and it's dedicated
Quoted 9 lines
Quoted 3 lines · Arun Ravindran
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:]
Quoted 2 lines
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... ;)