sdl_evolution 🚀 - [Deferred] SDL 0245 - WiFi Transport: Sharing SSID and password with Mobile Proxy

This would be a vast improvement over the existing situation.

2. The iOS details use iOS 11.0+ APIs, but the iOS library supports iOS 8.0+. Please provide details on what to do with older devices.

3. There is no discussion of the consent of the user to connect the device to the WiFi network. Please provide details on how the user's consent to connect to that WiFi network should be accomplished. Is this automatic through iOS (I was unable to test the example code you provided due to the need for Apple entitlements, see below, 4)? What are the driver distraction implications?

4. The iOS details for connection require Network Extensions methods. But these methods require special entitlements from Apple to use. Please provide details on if you intend all video streaming developers to go through the process of getting this information.

EDIT: (1) was found to be irrelevant, so I edited to remove it.

joeljfischer on 31 Jul 2019

A concern of mine is the broadcasting of network information. I know in the proposal it is stated that changing passwords is recommended, but based on the language it is not guaranteed to happen.

In the case that a user changes the wifi password on their head unit, would it broadcast 2 SSIDs (the network SSID and PW set by the user, and one for SDL)? Otherwise this could expose customer information (many people probably would use the same wifi password as they do at their homes).

Additionally, exchanging the data in a Control Frame, which to my knowledge, at this point in SDL is not and can not be encrypted. If someone like @JackLivio could confirm, I'd be appreciative. If this cannot be encrypted, I highly advise finding an alternative route for this information to be securely passed through, or wait until a total encryption solution is integrated into SDL.

BrettyWhite on 31 Jul 2019

Also, would SDL developers be forced to implement:

<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />

or would that permission be optional? I can think of many cases where application developers and users would not like to see apps that are free to change WIFI states.

BrettyWhite on 31 Jul 2019

Thank you @joeljfischer and @BrettyWhite for reviewing this proposal.

In case of an older iOS device, the library will not try connecting to WiFi on receiving transport event update. In this case, I propose to keep behavior as it is today. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.
Yes, the iOS device manages this.
iOS device would show popup to the user to allow WiFi connection. I would think that in case of WiFi connection is not established due to pop up being ignored or the user does not allow it. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

In case, the concern is regarding pop up being shown to the user while driving, the library may not attempt automatic WiFi connection when it receives Driver distraction ON notification. However, I do not think we should do this, because:

secondary transport is required for high bandwidth requirement, video streaming apps, the user would anyway need to launch the app and keep it in the foreground on the phone when using that app on SYNC.
Driver distraction rules are not applicable to all countries.
Users can always neglect pop-ups shown on the iPhone screen when driving.

We will need to provide an API to the app developer to set a WiFi autoconnection flag. If this flag is set library will attempt auto-connection on receiving credentials. If this flag is unset, the app does not attempt connecting to WiFi. For example setAutoConnectWiFi in SDLManager iOS. Please do let us know if you have any other suggestions.

In the case of Android, we can achieve this behavior by checking if permissions are granted. So, we do not need a flag stated above. If permissions are granted then the library will attempt WiFi connection otherwise it won't.

but based on the language it is not guaranteed to happen.

True. HMI can decide this behavior.

In the case that a user changes the wifi password on their head unit, would it broadcast 2 SSIDs (the network SSID and PW set by the user, and one for SDL)?

No, proxy will receive only one SSID. As mentioned in a proposal. 0141-multiple-transport we need to provide network interface in smartdevicelink.ini file for SDL Core. The system should provide WiFi credentials of network active on specified network interface.

... expose customer information

This details will be provided by primary transport. I believe the security provided by this transport is enough to communicate network credentials. SDL enabled apps currently uses these transport to communicate a wide range of data including private data such as location info.

Regarding App permissions in Android:

Apps should request these permissions. As mentioned in the guide here.They should provide an appropriate rationale for using this permission so that the user can make an informed decision whether they should allow the app to connect or not. The proxy should attempt WiFi connection only if permissions are granted.

ashwink11 on 1 Aug 2019

As mentioned in a proposal. 0141-multiple-transport we need to provide network interface in smartdevicelink.ini

True this provides an interface, but it does not provide security credentials. The current implementation assumes the devices are on the same network and the primary transport provides an address.

It looks like as of protocol V5, control frames can be encrypted (https://github.com/smartdevicelink/sdl_core/issues/2142). Maybe for this feature we should require protected services due to the increased risk of transmitting credentials

BrettyWhite on 1 Aug 2019

2.

HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

I think this proposal should specify which and how. Specifically, the HMI should do it based on the RegisterAppInterface DeviceInfo struct.

3.

a.

I would think that in case of WiFi connection is not established due to pop up being ignored or the user does not allow it. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

How would the HMI know unless we added an RPC? Or the app, for that matter? Only the proxy library would know unless this proposal added an interface between this code and the app and wants to burden the app developer with displaying a message to the user via either the phone or SDL?

b.

In case, the concern is regarding pop up being shown to the user while driving, the library may not attempt automatic WiFi connection when it receives Driver distraction ON notification. However, I do not think we should do this, because:

I think that we should prevent this from happening while the driver is distracted.

secondary transport is required for high bandwidth requirement, video streaming apps, the user would anyway need to launch the app and keep it in the foreground on the phone when using that app on SYNC.

While this is true, this is a far less than ideal situation, and we'd be adding an additional popup that users would have to read and respond to, on their phone, while distracted driving. This is illegal in many jurisdictions.

Driver distraction rules are not applicable to all countries.

So we ignore them where they are applicable?

Users can always neglect pop-ups shown on the iPhone screen when driving.

But will they? If they're attempting to accomplish a task and the HMI (I'm assuming) is directing them to read and respond to a popup on their phone, they are unlikely to neglect this task and simply abandon what they're trying to do.

4. Your response did not answer this question. I want to be clear; we are asking all video streaming app developers to request this entitlement from Apple, correct? What if Apple denies this request? Have you talked to Apple about this feature?

I do agree, however, that consent needs to be given by the developer to enable this feature through their app as well, and a StreamingMediaConfiguration option should be added, disabled by default.

I'm going to assign Brett's first point as (5):

This details will be provided by primary transport. I believe the security provided by this transport is enough to communicate network credentials.

There is effectively no security on this transport and it can be read by the app, or, theoretically anyone with a man-in-the-middle attack. I don't know what you mean by:

This details will be provided by primary transport...SDL enabled apps currently uses these transport to communicate a wide range of data including private data such as location info.

If by this you mean that SDL apps transmit data over without encryption over the RPC protocol, you are correct, but WiFi passwords seems like a next level issue, primarily because it's not information that the app is already knows. They already know the user's location, but they definitely do not know their WiFi password.

New items:

There is no information on detecting if the device is already connected to the target wifi network. Is this handled by the APIs already, or is this something that needs to be added? The HMI has no way of knowing if the device / app is already connected to the WiFi network, so it will probably always have to transmit those credentials.

joeljfischer on 1 Aug 2019

I do believe a feature like this needs to be included to actually make WiFi as a secondary transport viable. I do have some concerns including the already stated concerns over user consent and security vulnerability.

3.c.
User consent is important, if the phone switches over to connect to the module's WiFi AP, it is assumed that all other internet traffic would go through this connection as a first attempt. This could eat at the data plan in the vehicle as an unintended action of connecting to it. For example, if a Navigation app implements this behavior, switches the WiFi while the user is also streaming music, the music will start streaming over the module's modem if an internet connection is active. This could incur cost to the user, app, or OEM.

5.b.(?) I don't believe the answer provided for using<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" /> is clear. Are all app developers going to be requested to include this new permission? Is it possible we give them an explanation of why it's needed? Pushing it off on the developer will likely be a poor choice. Developers are very cautions about what permissions they are adding to their apps so this is an important issue that can't be skimmed over.

7.

If MultipleTransportsEnabled is set as true and SecondaryTransportForBluetooth is WiFi in smartDeviceLink.ini configuration file. HMI should create a WiFi Access Point and the WiFi credentials should be communicated to the mobile proxy.

Is this a hard responsibility of the HMI? I'm not sure if all HMI's will have access to the APIs that can turn on a WiFi Access Point, and to create one with dynamic credentials.

8.

  <function name="OnWiFiTransportAvailable" messagetype="notification">
      <description>HMI must notify SDL about WiFi Access point.</description>
        <param name="ssid" type="String" minlength="1" maxlength="30" mandatory="true">
        <description>name of the WiFi ssid</description>
      </param>
        <param name="password" type="String" minlength="1" maxlength="30" mandatory="true">
        <description>password to use to connect AP</description>
      </param>
        <param name="securityType" type="WiFiSecurityType" mandatory="true">
        <description>security type of WiFi AP</description>
      </param>
  </function>

Is there a reason why the maxlength is 30 for both ssid and password? SSIDs can be up to 32 characters, and I believe the passcode low max limit is 63 characters.
Also the parameters are all mandatory, would it make sense if the access point didn't have a password and used WIFI_SECURITY_NONE? For xcample the SSID isn't broadcasted but is changed each connection which would make it about as secure as sending the password through plain text but no need for the password param. I would vote that password is moved to mandatory=false.

9.

When will the app connect to the WiFi AP? As soon as it gets the update?I would assume no. How about when the app requests a service to be started that requires a WiFi connection? What happens if multiple apps are trying to connect the phone to that network at the same time?

10.

On successful connection or if the mobile device is already connected to WiFi access point mentioned in Transport Event Update, core and proxy should follow use case described in a proposal Supporting simultaneous multiple transports.

There is a bit of hand waving to this piece. How will the mobile libraries know that there was a successful connection to the network?

joeygrover on 1 Aug 2019

The proposal is created keeping in mind, that apps can communicate/work with HMI using primary transport i.e. USB or Bluetooth and secondary transport configured in smartDeviceLink.ini file is WiFi. WiFi is required only for high bandwidth data requirements, for example, Video streaming Apps.

If Apps want to use secondary transport, they can choose, if they want to use the WiFi auto-connect feature or not. If so, they would need to add entitlements or permissions. If not user can manually connect WiFi and use their App.

The proxy should provide APIs to configure on/off WiFi auto-connect feature.

2.
From this proposal, ...HMI may implement an error message stating that Wi-Fi or USB transport is required for a mobile projection app to work.

Although the above-mentioned proposal is for App resumption. I would propose to extend the behavior of HMI showing error message... to video streamings apps registered using just primary transport.
Please do let me know your thoughts. For template-based Media and Non-media apps, they will continue to work using primary transport.

3.a.
We do not need any new RPC to let HMI know that WiFi connection failed. I do not think, HMI would need this information. If proxy failed to connect WiFi, HMI will consider a case similar to point 2 discussed above and HMI should show an appropriate message to the user that WiFi needs to be connected to use App.

3.c.
A mobile device will show user consent pop-up for either requesting permission (Android) or before connecting WiFi(iOS). These pop-up are managed by the system. If we add one more pop-up, there will be two pop-ups in total to connect to WiFi. I would recommend this user consent to be added in HMI which would be shown once when the device connects to WiFi on HMI.

This could eat at the data plan in the vehicle as an unintended action of connecting to it. For example, if a Navigation app implements this behavior, switches the WiFi while the user is also streaming music, the music will start streaming over the module's modem if an internet connection is active. This could incur the cost to the user, app, or OEM.

This issue would come even if the user manually connects to WiFi. So, I recommend showing this SDL specific user consent on HMI.

4.
I did not speak to Apple. If the request of entitlements is denied, the app developer needs to disable WiFi auto-connect, as suggested in your comment, using StreamingMediaConfiguration. The proxy will not connect WiFi if this setting is disabled. User will need to manually connect WiFi to use Apps.

5.
As @BrettyWhite pointed out encryption is already available in protocol V5, this proposal does not change this behavior.

WiFi passwords seem like a next-level issue

I am not a data privacy expert, but I do not agree with this statement. On researching further on this issue, location data is considered as Personally identifiable information (PII) from here.
I would still consider security provided by primary transport should be enough to share WiFi credentials of a non-stationary device if this was working without any issue earlier for other data.

Also, if we compare other solutions, like Wireless projection, Android Auto and CarPlay, credentials are transferred using Bluetooth using their respective protocols. Not that I want to copy their solution "as is", but I don't see any reason for not implementing this proposal in the dearth of encryption capability.

5.b
No, all apps do not need to request these permissions. As discussed for iOS, an API should be provided for Android as well, so that App developer select if they want to enable/disable WiFi Autoconnect. If this setting is enabled, the android proxy will check if these permissions are "granted" before attempting a WiFi connection.

In the case of iOS proxy, if WiFi auto-connect is enabled, the proxy can directly use APIs to connect WiFi.

6.
In that case, iOS API to connect WiFi will return error "already associated".

However, APIs are available to get current WiFi information as well. In iOS new entitlement need to be used, please find info here.

If we are concerned about App getting Apple approval to use entitlements. We can rely on the error returned by iOS API's.

7.
Usually, on Linux, Android and QNX platform, a component called "wpa_supplicant" are used. HMI can use APIs provided by this component to create access point either by using predefined credentials or dynamically created credentials.

8. I will include changes as mentioned.

9.

When will the app connect to the WiFi AP? As soon as it gets the update?

I assume, as soon as WiFi credentials are available, the proxy can start a connection.

How about when the app requests a service to be started that requires a WiFi connection?

a. If the proxy tries WiFi connection when service is to be started, it will delay the App use case, as service would start when App is launched by the user on HMI.
b. In case, WiFi connection from proxy fails due to some reasons, HMI will have to wait, first for WiFi connection and then for Service setup, downloading certificates and so on.

Could you please share your thoughts on not connecting WiFi as soon as credentials are available?

10.
The proxy should check the error callbacks and return values provided by platform APIs. In case of any errors or WiFi connection failed, the proxy should consider case similar to point 2 discussed above and rely on the user to connect manually.

Alternatively, the proxy could use additional permissions to access current WiFi connection state and check if the connected WiFi is the same as that received from the core. However, as stated above there are concerns regarding Apple approving required entitlements.

ashwink11 on 2 Aug 2019

From your intro:

If Apps want to use secondary transport, they can choose, if they want to use the WiFi auto-connect feature or not...The proxy should provide APIs to configure on/off WiFi auto-connect feature.

There is no API in the proposal to enable / disable this, are you saying that it will be added in a revision of the proposal?

2.

I would propose to extend the behavior of HMI showing error message... to video streamings apps registered using just primary transport.

This cannot be the case. USB is a primary transport (at least on iOS).

3.a.

We do not need any new RPC to let HMI know that WiFi connection failed. I do not think, HMI would need this information. If proxy failed to connect WiFi, HMI will consider a case similar to point 2 discussed above and HMI should show an appropriate message to the user that WiFi needs to be connected to use App.

How would the HMI get this information otherwise? Unless you're assuming that the HMI would communicate with the network chip. But even then, how would it know that the correct device connected?

3.b. Has not been responded to.

3.c.

If we add one more pop-up, there will be two pop-ups in total to connect to WiFi. I would recommend this user consent to be added in HMI which would be shown once when the device connects to WiFi on HMI.

If the consent is only added after the connection to the WiFi network, then it would have to disconnect from the network. If they were connected to a different network, they would now be disconnected. The consent prompt would have to happen before the device prompt.

4. I would appreciate if you could add language to this proposal specifying that all apps supporting this feature will have to request entitlements from Apple, along with a link to the place developers will have to go to in order to request the entitlement. There should also be language in the proposal that this information should be added to the app certification guidelines as well. Finally, I would recommend that the Developer Relations Committee talk to Apple about this feature.

5.

As @BrettyWhite pointed out encryption is already available in protocol V5, this proposal does not change this behavior.

I've believe that this control packet is not encryptable because it's on the control session. This password would be plaintext.

I am not a data privacy expert, but I do not agree with this statement. On researching further on this issue, location data is considered as Personally identifiable information (PII) from here.

You're missing my point here. When we provide location details, we're not providing the developer of the app with something they don't already have. Plus, the user has a consent dialog that they need to pass through before any vehicle data is shared.

I would still consider security provided by primary transport should be enough to share WiFi credentials of a non-stationary device if this was working without any issue earlier for other data.

Transports generally do not provide security. There is no security inherent to Bluetooth, for example, so I'm not sure your statement makes sense.

Also, if we compare other solutions, like Wireless projection, Android Auto and CarPlay, credentials are transferred using Bluetooth using their respective protocols.

I want to clarify. You're saying that AA and Carplay transmit wireless SSID and password over Bluetooth in plaintext? Even if that's the case, these credentials are not provided to the app developers, like they would be here, correct?

Using the error is probably a just fine way to go.

9.a.

If the proxy tries WiFi connection when service is to be started, it will delay the App use case, as service would start when App is launched by the user on HMI.

I'm not sure, but is the TransportEventUpdate not sent when the video service starts?

b.

In case, WiFi connection from proxy fails due to some reasons, HMI will have to wait, first for WiFi connection and then for Service setup, downloading certificates and so on.

How would the HMI know that the connection failed? What are the retry cases here? Is there a timeout for failure (e.g. 10 seconds)?

joeljfischer on 2 Aug 2019

There is no API in the proposal to enable/disable this, are you saying that it will be added in a revision of the proposal?

Yes, I will add this in revision.

From proposal 0141-multiple-transports

Secondary transport for Bluetooth can be configured using smartdevicelink.ini file. So, I understand, primary transport can be Bluetooth. Please do let me know if this is changed now.

3.a.

How would the HMI get this information otherwise?

HMI will not get any information for failed WiFi auto-connect. Proxy as well could not do anything if Wifi auto-connect failed. User will need to connect WiFi manually, as they would do today to use the app.

3.b & 3.c.

I will get back to you on this.

Sure, I will add the following info.

Steps to enable entitlements:

Apple developer/enterprise account needed to add required entitlement in provisioning profile.
Enable required entitilements for your project in XCode.
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_hotspotconfiguration
https://help.apple.com/xcode/mac/current/#/dev88ff319e7

As per link below, we need not request entitlement from Apple if we are using Wi-Fi Configuration.
https://stackoverflow.com/questions/40285863/network-extension-entitlement-how-to-enable-it

5.

You're missing my point here. When we provide location details, we're not providing the developer of the app with something they don't already have. Plus, the user has a consent dialog that they need to pass through before any vehicle data is shared.

From the previous comments about "man-in-the-middle attack", I understand that point 5 was about concerns regarding transferring data to mobile device on unencrpted channel and not about who is going to receive it. We will also have user consent pop up as discussed in point 3 above to share and auto-connect WiFi.

I was saying that until recently SDL used transport without encryption to transfer data to the mobile device.

The information in AA and CP is sent as per their protocol. As SDL has its own protocol, it would be a similar case. Also, you might be aware that iAP2 has its own authentication mechanism. This authentication mechanism is used for iAP2 connection for SDL as well.

9.a.

Please check section Transport disconnection

TransportEventUpdate will be sent, if WiFi transport becomes unavailable,

9.b.

HMI will not get any information for failed WiFi auto-connect. Proxy as well could not do anything if Wifi auto-connect failed. User will need to connect WiFi manually, as they would do today to use the app using WiFi.

ashwink11 on 5 Aug 2019

3.c

We propose to show user consent on HMI.

HMI shows user consent to share WiFi details and auto-connect with the mobile device.
If the user allows, Transport Event Update sent with WiFi credentials
Mobile proxy attempts WiFi auto-connect feature if it's enabled by App.

ashwink11 on 5 Aug 2019

5.

From the previous comments about "man-in-the-middle attack", I understand that point 5 was about concerns regarding transferring data to mobile device on unencrpted channel and not about who is going to receive it. We will also have user consent pop up as discussed in point 3 above to share and auto-connect WiFi.

User consent does not mean that we should not to the right thing with protecting / encrypting their data. Just because it adds complexity does not mean that it should be ignored.

I was saying that until recently SDL used transport without encryption to transfer data to the mobile device.

Unless the transport is protected, the data is plain text. I don't recall seeing language that using this system will require encryption, such as video streaming currently does.

Carplay encrypts their data, while SDL partially does, in certain cases (such as video streaming). see page 29: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

Per the discussion during the meeting regarding RPC Message protection, it was agreed that a transport level encryption should be added, and this is a perfect example of how that would be helpful.

This authentication mechanism is used for iAP2 connection for SDL as well.

What about the android devices over BT? AOA?

EDIT: added discussion number for easier following

BrettyWhite on 5 Aug 2019

5.

Carplay encrypts their data, while SDL partially does, in certain cases (such as video streaming).

Can we please limit our discussion to WiFi credentials sharing?

see page 29: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

Page 29 in the shared document refers to HomeKit. I am not able to find any info in this shared document where it says, WiFi credentials shared are encrypted for CarPlay.
Could you please let me know correct page no.?

If you have access to Apple iAP2 spec, I would recommend you to check that. Unfortunately, we won't be able to share iAP2 spec details.

ashwink11 on 6 Aug 2019

3.b.
I will include in a proposal that, the proxy should attempt WiFi auto-connect when DD is OFF.

ashwink11 on 6 Aug 2019

Can we please limit our discussion to WiFi credentials sharing?

You used AA and CP as an example above before I brought it up, I was simply continuing that discussion.

From page 29 at the top:

AirPlay audio and CarPlay video streams utilize the   MFi-SAP (Secure Association Protocol), which encrypts communication between the accessory and device using AES-128 in CTR mode. Ephemeral keys are exchanged using ECDH key exchange (Curve25519) and signed  using the authentication IC’s 1024-bit RSA key as part of the Station-to-Station (STS) protocol.

You are correct, we do not have the iAP2 spec. However, that only covers half of all SDL users.
Please also discuss how you plan to handle Android's transports. In my eyes, this is entirely necessary for a proposal like this to be resolved before this is approved and implemented.

BrettyWhite on 6 Aug 2019

You used AA and CP as an example above before I brought it up, I was simply continuing that discussion.

I brought up WiFi credentials sharing for AA & CP in the discussion. I never said video streaming is not encrypted. Video streaming can be encrypted in SDL as well.

I mentioned AA and CP, to mention that they use Bluetooth to share WiFi credentials using their respective protocol.

From my previous comments,

I was saying that until recently SDL used transport without encryption to transfer data to the mobile device.

If we can use Bluetooth for transferring location data which is considered as Personally identifiable information (PII), then why not WiFi credentials?

Edit: Added Context to bring AA and CP in discussion

ashwink11 on 6 Aug 2019

If we can use Bluetooth for transferring location data which is considered as Personally identifiable information (PII), then why not WiFi credentials?

Just because something is doesn't mean it should be. I agree with you above this is getting a bit out of context so this will be my last comment on this. I just believe that we, as stewards of the platform, should be the ones protecting the users.

With that said, I believe the easiest solution would be to enforce encrypted services for apps that wish to use this feature. We can create a new RPC that uses the new RPC message protection feature to ensure the data is secure, instead of using a control frame.

Thanks

BrettyWhite on 6 Aug 2019

👍4

3a.

I would think that in case of WiFi connection is not established due to pop up being ignored or the user does not allow it. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

HMI will not get any information for failed WiFi auto-connect. Proxy as well could not do anything if Wifi auto-connect failed. User will need to connect WiFi manually, as they would do today to use the app.

But that's my point! You said earlier (the first quote above) that the HMI or app should show a message, and now you're saying that it can't get the information it would need. So then we're on to the app showing the information. Which is probably fine on iOS, due to the user already having to use the phone to allow or deny the Wi-Fi connection on iOS. But on Android is much less than ideal, where the user _doesn't_ have to interact with their device, so having it all on the HMI is the ideal user interaction. So then, we're back to needing a notification to the HMI that the connection failed.

I'd also like to see recommended text, such as (on iOS), "Your device failed to connect to your vehicle's Wi-Fi. Please connect your device manually using these credentials: \credentials here\".

3c. Is the consent prompt going to be saved for future uses (does it display only once), or does it appear every time (probably what should happen). I'd also like to see some recommended language, such as (on iOS) "Would you like to connect to this vehicle's Wi-Fi? Selecting YES means that you will be prompted on your device."

joeljfischer on 6 Aug 2019

Here's a summary of the current status of this discussion, for review during our call.

Agreed Upon Items
2. Proposal should be updated to note that pre-iOS 11.0 devices cannot support this feature and that the HMI will display as such based on the RAIR DeviceInfo struct.
3b. Specify that proxy should attempt WiFi auto-connect when DD is OFF.
4. Add language to specify entitlement request procedures, and that this information should be added to the SDLC Application Certification Guidelines.
5b. Add API so developer can enable/disable WiFi auto-connect.
6. Clarify that we will rely on the error returned by iOS APIs for checking if it's already on the wifi network.
8. Update onWiFiTransportAvailable function per https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-517439904.

Items Still in Discussion
3a. Project Maintainer looking for details on how the HMI will display that a connection failed.
3c. Determine recommended language for user consent screen that will be shown before requesting on the phone.
5a. Project Maintainer believes user's WiFi password should be encrypted; author believes this should be plain text. Other Steering Committee members should weigh in.
7. Author to advise how the HMI will get access to the methods available on the system.
9a. Project Maintainer to review and provide feedback.
9b. Project Maintainer to review and provide feedback.
10. Author to provide code examples to assist with discussion.

_Note:_ Item 1 was found to be irrelevant so was removed from discussion.

theresalech on 6 Aug 2019

The Steering Committee voted to defer this proposal, keeping it in review until our next meeting on 2019-08-20, to allow the author, Project Maintainer, and other SDLC Members to finalize discussion of the open items noted in this summary comment.

theresalech on 7 Aug 2019

& 3.a.

In previous comments, the discussion went on regarding support of Bluetooth as primary transport in Point 2, hence did not discuss other possibilities. HMI knows App HMI type of Application registered and Transport type. HMI can use this info to alert the user to connect to secondary transport.
_Using RAIR device info is not necessary._

One of the possible flow depending on HMI implementation and SDL configuration is:

a. If multiple transports are enabled in smartdevicelink.ini
b. If System implementation allows video streaming app to register using primary transport.
c. HMI knows App HMI type of Application registered and Transport type.
d. If secondary transport of Bluetooth is set as WiFi in smartdevicelink.ini
e. Secondary transport is not connected.
f. HMI checks App HMI type and transport type, and show an appropriate message to the user to connect Secondary transport to use App.

In this flow, we cover both cases where System is connected to a pre-iOS11 device or when WiFi Autoconnect failed. HMI would alert the user to connect to secondary transport using App HMI type and Transport type. This way, HMI does not need any info regarding WiFi auto-connect failure, as it can determine itself using existing information available, that secondary transport is not connected.

As you know, a lot of things depends on OEM's preferred implementation, SDL configuration in smartdevicelink.ini file set by HMI like, whether multiple transports are enabled, whether Bluetooth as primary transport can be used, whether WiFi is secondary transport, etc.

This proposal does not make any recommendations regarding the use of primary transport or secondary transport or the flow mentioned above. The flow mentioned above is just an example for understanding.

This proposal mentions only sharing WiFi credentials and WiFi auto-connect from the proxy. Hence, I do not prefer to write any recommendations text for HMI. OEM's can decide if they want to use RAIR device info and text they want to use depending on their preferred implementation.

5.a.

We do appreciate your concerns regarding users and the great work you guys do.

However, we should also make sure that the solution we design is adaptable, comparable and competing with other solutions in the market. We do not want to make it harder to adapt SDL, compared to AA and CP, when we talk about Wireless projection.

Regarding your suggestion, we like this idea. I can make changes in proposal to use RPC, that would use RPC message protection feature, instead of the control frame. OEM can configure ON/OFF encryption using their policies depending on their preference.

The information was provided to answer a query regarding dynamic credentials for WiFi AP. I believe query came as changing passwords were mentioned in the "Motivation" section of the proposal to describe a possible scenario.

However, I do not propose anything related to configuring or creating WiFi AP. This depends on the discretion of OEM. Hence, out of scope for this proposal.

This point never came to discussion before. Some sample codes are already provided in the proposal.

ashwink11 on 7 Aug 2019

5.a

Awesome, that should work. 👍

BrettyWhite on 7 Aug 2019

👍1

2/3a. I think I need clarification here, because it doesn't look to me like you've provided a flow that solves what you say it does.

In this flow, we cover both cases where System is connected to a pre-iOS11 device or when WiFi Autoconnect failed.

Where does this cover either of those cases? The flow you've provided doesn't mention either. I don't see how knowing the AppHMIType has any effect on this. For example, if an iOS 8 device connects, it can go through this whole flow, and the HMI doesn't know that the WiFi autoconnect won't work without the RAIR DeviceInfo struct.

HMI would alert the user to connect to secondary transport using App HMI type and Transport type. This way, HMI does not need any info regarding WiFi auto-connect failure, as it can determine itself using existing information available, that secondary transport is not connected.

I don't think so. The problem is that the HMI can't know if the secondary transport is connected or not due to the nature of WiFi.

This proposal mentions only sharing WiFi credentials and WiFi auto-connect from the proxy. Hence, I do not prefer to write any recommendations text for HMI. OEM's can decide if they want to use RAIR device info and text they want to use depending on their preferred implementation.

We need to provide HMI integration and implementation guidelines for OEMs and flows that their HMIs will need to adhere to for this feature to work consistently across platforms and well. I consider this a requirement for this proposal, though of course, it's up to the SDLC.

5a. I think we're in agreement here that making this an RPC so as to allow or require encryption on it is the better way to go. However, I do still have concerns that these passwords will be available to the app developer. A bad actor app developer would be capable of harvesting these passwords, and putting the encryption over the wire on it does not help that situation.

This is a very tricky problem to solve. I think the only way to mitigate it is to require HMIs to disclose this when they ask for consent to auto-connect.

joeljfischer on 8 Aug 2019

2/3a.

I don't think so. The problem is that the HMI can't know if the secondary transport is connected or not due to the nature of WiFi.

From the information provided in proposal SDL-0141, the proxy needs to register secondary transport.

If WiFi is not connected, then Proxy cannot register secondary transport and hence HMI knows video streaming App cannot work and alerts the user to connect WiFi.

In case the iOS 8 device is connected or WiFi auto-connect fails, HMI knows secondary transport not connected and alerts the user to connect WiFi.

We need to provide HMI integration and implementation guidelines for OEMs and flows that their HMIs will need to adhere to for this feature to work consistently across platforms and well. I consider this a requirement for this proposal, though of course, it's up to the SDLC.

I do not propose any changes in the existing SDL WiFi implementation. This proposal is just an add-on to provide convenience to Users. HMI integration and implementation guidelines for OEMs would be a much broader topic and should be discussed in another proposal.

This proposal, as I mentioned would provide a way to share WiFi credentials to Proxy and Proxy trying auto-connection.

5a. Yes, user consent will be provided on HMI to share WiFi credentials. We will bring RPC changes with the revision.

Edit: Added text.

ashwink11 on 9 Aug 2019

2/3a.

If WiFi is not connected, then Proxy cannot register secondary transport and hence HMI knows video streaming App cannot work and alerts the user to connect WiFi.

So, you're saying that there's a timeout? e.g. That Core sends a TransportEventUpdate, then waits a certain period of time to see if it sends a startService on the secondary transport, then if it doesn't within that timeout, will display the message to the user? If that is what you're saying, I don't think it was made clear, and would need to be added to this proposal.

However, it still doesn't cover all of the use-cases. When does the consent prompt appear in this flow? It can't appear for iOS 8 devices, but should for iOS 11, even if neither are already connected. I believe that you need to add detailed flow diagrams for all possible use cases (pre iOS 11, iOS 11+, and Android) and I think you'll see that you're not covering all of your required cases with the proposal thus far.

We need to provide HMI integration and implementation guidelines for OEMs and flows that their HMIs will need to adhere to for this feature to work consistently across platforms and well. I consider this a requirement for this proposal, though of course, it's up to the SDLC.

I do not propose any changes in the existing SDL WiFi implementation. This proposal is just an add-on to provide convenience to Users. HMI integration and implementation guidelines for OEMs would be a much broader topic and should be discussed in another proposal.

I'm not saying that you need to add additional information for any changes, because you're correct in saying that you haven't altered the existing feature. I'm saying that you need to add additional information because you're adding a new feature. The added stuff is the reason why you need to add additional HMI integration information! Perhaps the SDLC disagrees, but we have consistently to this point required proposals that make broad new features impacting the HMI to discuss how those features should be used (for example with the widgets proposal). I see it as no different in this case. It makes no sense to propose the technical requirements for implementation, then add a proposal discussing HMI requirements on how it should be used. The entire impact of this feature should be in the proposal.

This proposal, as I mentioned would provide a way to share WiFi credentials to Proxy and Proxy trying auto-connection.

And that's great, and this proposal will be a great addition, but it's pointless if HMI integrators don't know how to implement it, or if implementations conflict, or if implementation isn't possible because not all use-cases can be covered. Proposals are _not_ merely technical. They are proposing a _feature_ and that includes technical, business, server, impact, HMI guidelines, etc. as needed based on the feature's scope. I don't believe that you can limit the scope of this feature to merely the technical, because it has a much wider impact.

joeljfischer on 9 Aug 2019

2/3.a

When does the consent prompt appear in this flow?

Timeout, as you suggested, is one of the possibilities. Another possibility is that the user is notified when they want to launch the App on HMI. The HMI can say, "Connect WiFi to continue using App on System"

However, as you know, this depends on OEMs implementation. In case, primary transport is USB, HMI may allow using video streaming apps, without connecting WiFi.
In case primary transport is Bluetooth, HMI may not allow registration of Video streaming apps.

If WiFi is not connected, then Proxy cannot register secondary transport and hence HMI knows video streaming App cannot work. HMI can use a timeout or notify the user when they want to launch the app.

I would think, behaviour mentioned above is one of the possible flows irrespective of mobile device used for SDL. Please do let me know if you think the behavior would different for different devices.

In case of iOS 8 or iOS 11 or Android, the user would need to connect WiFi manually if API support to WiFi connection is not available or connection failed for some reasons and with the alert on HMI, HMI will communicate to the user that they need to connect to WiFi manually to continue using/launch App on system.

implement it, or if implementations conflict, or if implementation isn't possible because not all use-cases can be covered
I don't believe that you can limit the scope of this feature to merely the technical, because it has a much wider impact.

Could you please mention specific cases, where implementation is not possible or use case is not covered because of this proposal?

If we consider this proposal along with proposal SDL-0141. I think, the flow is complete. However, do let me know, in which specific cases, it's not and we would try to complete it.

ashwink11 on 12 Aug 2019

I want to take a step back here and give you insight into _why_ I'm making the comments I am. I think that my general concern here is for other OEMs who view this feature and are unclear on the requirements. Because Ford is introducing this feature, I'm sure that they have a set of requirements that they plan to implement into their head unit and are trying to ensure that they get this feature into the code so that they can implement their requirements. My concern is for OEMs who _don't_ currently have requirements set for this feature but because it's available in the open will want or need to implement it.

So I want to be able to provide those other OEMs who investigate or want to build requirements around this feature to ensure that they have good, ready to go integration guidelines, SDL requirements, and feature flows that they can use to evaluate this feature with their own systems, and so that they don't build incompatible systems. We've come across the issue of integration issues in SDL due to a lack of definition to the behavior. That's why the general tone of my comments is the way that it is, and it's why I'm pushing for feature flows and integration requirements for as many edge cases as we can come up with, and it's why I don't view this as simply a technical feature proposal. This is something that will have to be evaluated at other OEMs months or years from now, and we will need adequate documentation to describe how this must be implemented and the various corner cases that we know about.

So, we don't necessarily need to provide hard _requirements_, but we should at least provide _recommended_ flows that other OEMs can use when evaluating and building their own requirements for this feature implementation into their head units.

So I think the flow that I'm looking for is that which I mentioned in my above comment. A recommended flow from initial connection through the Wi-Fi auto-connect through final connection and startup including example popups that would appear (including where and when). This would also include comments on flows that would be needed for pre-iOS 11 devices and so forth. Does that make sense?

joeljfischer on 15 Aug 2019

After enabling multiple transports in SDL, there are multiple combinations of transport in which SDL can work. The case you described above is not introduced by this proposal, but it is applicable for all combinations when secondary transport is not connected. For example: consider a case where primary transport is Bluetooth and secondary transport is USB(Out of scope for this proposal though).

I would think that the above issue should be addressed in the proposal, where the behavior of SDL when secondary transport is unavailable, is defined. Not sure, if this is already discussed. Secondary transport could be any permissible transport defined by SDL.

Since you emphasize on adding it in this proposal, I will make the below recommendations. Please do review and let me know in case of any issues.

This recommended HMI flow is applicable only when secondary transport is WiFi.

a. HMI allows App registration of all apps using primary transport.
b. HMI knows App HMI type of Application registered.
c. HMI knows Transport type of the registered App. Information will be available to HMI with HMI API's BasicCommunication.OnAppRegistered and BasicCommunication.UpdateAppList. Please refer proposal SDL-0141 for details.
d. Secondary transport is not connected.
e. In the case of Video streaming Apps, HMI does not allow App activation using primary transport.
f. User tries to launch the App on System.
g. HMI checks App HMI type and transport type received from SDL Core in Common.HMIApplication.
h. HMI determines, that App activation is not permitted as secondary transport is not connected.
i. HMI shows an appropriate message to the user to connect secondary transport to use the App. HMI can show the message, "Connect WiFi to continue using App on System".

ashwink11 on 16 Aug 2019

The reason I asked this question was the same reason it was decided that the secondary TCP connection should wait until the user actually opens the app, it's a more responsible use of resources including the battery life of the device. I think this case is a little different though as they are likely to already be connected to a mobile network and WiFi might actually preserve battery life on the device. As long as the user consents to automatically connecting to the WiFi network I think connecting to the vehicle's WiFi network can happen as soon as possible.

Regarding Joel's post, I think we are more focused on the flow of joining the vehicle's network, not necessarily only the secondary TCP connection that was introduced in SDL-0141. There are a good deal of corner cases and flows that should be considered around joining the network that we simply want to make sure we have a guidance to give other members. It is difficult for the project maintainer to provide such guidance if it is not defined somewhere, and to ensure whatever guidance we give doesn't interfere with other member's implementation. Proposals like this will be used as the basis of those decisions, so if that information is missing it is a big disadvantage for anyone trying to integrate the feature. While other proposals might not have had specifics like this, that doesn't mean we should avoid them. The evolution process has been evolving itself, which is a good thing. We are learning that gaps exist and we want to prevent those gaps when we can. I apologize if it seems like we are trying to add an extra burden to the author, we simply want to make sure each solution/feature is as complete as possible from the start and the from the subject matter expert (author).

joeygrover on 20 Aug 2019

The Steering Committee voted to return this proposal for revisions. The author will update the proposal to include the "Agreed Upon Items" in this comment, as well as the following:

3a/7/10. Add flow of joining vehicle's network and code examples where applicable, including fail cases. Provide guidelines for use cases
3c. Author provides recommended language for user consent that will be shown before requesting on the phone.
5a. Update to use RPC Message Protection feature instead of control frame. OEM can configure ON/OFF encryption using policies. User consent will be provided on HMI to share WiFi credentials.
9a/b. Include that connecting to the vehicle's WiFi network can happen as soon as possible, as long as the user consents to automatically connecting to the WiFi network.

theresalech on 21 Aug 2019

Hi @ashwink11 we wanted to check in on these revisions. Do you have an anticipated completion date? Thank you!

theresalech on 4 Sep 2019

After thinking about this, and re-reading it. I am still concerned with 2 things.

RPC Message protection in this is optional, I strongly believe that for something as personal as sharing a wifi password with a 3rd party app, that we should take the high road here and make sure that our customers are as protected as they can be, especially now that that RPC protection feature will be available in the next core / proxy releases. I believe this should be a requirement.
The second could be an issue with the Android router service setup, where data flows through one app (the host), to the app requesting the RPC. A bad actor could skim this data, and with all of the SDL apps on the road, could amass a large quantity of user Wifi passwords. This one might be a bit harder to solve. Off the top of my head, it could be something as simple as using symmetric encryption from the HMI to the app, using a key that both would know.

I know that I keep bringing these up, but it is important to think about these things when this could be potentially used my millions of cars, and it should not be taken lightly. I'd bet that many people would consider using the same wifi password in their car as they do in other apps, or for their home wifi. Additionally, this is not a complex setup, it is quite easy to change from the car's default: https://www.youtube.com/watch?v=lN5hRHhADkQ

If this is something that might be easier to discuss in another forum or way, I'm more than happy to take a call or help figure something out, and I know a few others who might be as well. I believe this is a useful feature, and I think its possible to implement in a secure fashion 👍

BrettyWhite on 25 Sep 2019

As we agreed earlier, this RPC protection is optional. OEM can decide on RPC protection.
This proposal does not make any changes in RPC protected services implementation. The proposed RPCs should work as other protected RPCs.

ashwink11 on 25 Sep 2019

I understand that that’s what the RPC protection feature states, but I strongly believe that we should agree that Wi-Fi passwords require encryption, and so RPC protection should be required for this feature to function.

BrettyWhite on 26 Sep 2019

I agree to protect passwords by encrypting them.
BTW, I have a very fundamental question.
Why is HU become the AP?
I think that it is easier to connect to the Internet if the device is AP.

Shohei-Kawano on 1 Oct 2019

Thank you for your review @Shohei-Kawano
Yes, protected service can be enabled if required for your implementation. It's proposed as configurable.

I understand that iPhones cannot create AP programmatically. Hence, HU will create.

ashwink11 on 1 Oct 2019

@ashwink11 -san
Thank you for reply.
I understand the limitations of the iPhone.
My concern is: If the iPhone is a Wifi client and the HU is not connected to the Internet,
then iPhone cannot access the Internet.
In other words, since the SDL App is not connected to the Internet, I think that the function will be incomplete.
How are these resolved?
Or is my prediction wrong?

Shohei-Kawano on 2 Oct 2019

Hi @Shohei-Kawano,
Unfortunately, I won't be able to answer your query regarding Internet access. Probably this was discussed in some other proposals. Maybe you can ask project maintainers, they would have more information on this topic.

ashwink11 on 2 Oct 2019

@ashwink11, it is likely you are referring to the SDL0141 - Supporting simultaneous multiple transports proposal which defined a production TCP transport that the mobile libraries could use. In actuality, this proposal did not define any requirement that the head unit would be the network host, nor did it say the phone would be the host. The idea was to keep the transport agnostic to that requirement. Therefore the solution works for all scenarios.

On the other hand, your proposal specifically introduces a requirement that the head unit is the network host. Since this has never actually been agreed to in any other proposal, it will be your burden to defend the position that this requirement is the right path. The libraries will automatically connect to those head unit hotspots so the question left by @Shohei-Kawano is valid for this proposal and should be addressed.

joeygrover on 2 Oct 2019

It should be noted that during the 2019-10-01 Steering Committee meeting, the Steering Committee voted to defer this proposal, and keep it in review until our next meeting on 2019-10-08, so that more discussion about the proposal could take place on the review issue.

theresalech on 2 Oct 2019

My apologies, I was not aware that this was not discussed earlier.

I understand that iPhones cannot create AP programmatically. In android there are no such limitations except few permissions would be required.

If the mobile device is creating an AP then

internet connectivity would be preserved
iPhone device users would need to create Wi-Fi AP and connect devices manually.
WiFi can connect automatically only for android devices. If it needs to be supported for android devices, then this would require logic in proxy to select the app that would create an AP and pass on Wi-Fi credentials to HU. Also, this would depend on app developers if they allow their app to create Wi-Fi AP.
If multiple mobile devices are connected to Wi-Fi they would use the internet from mobile devices creating Wi-Fi AP.

If HU creates an AP and does not provide internet connectivity, then

Internet connectivity for some devices could be hampered and would need user action. iPhones would switch to mobile connection for the internet but on some android devices, the user needs to enable settings to get this behavior.
WiFi auto-connect could be supported for both Android and iOS devices (restrictions already mentioned in the proposal)

Since both methods have their pros and cons. The Steering Committee can decide whether to follow any particular approach or keep it transport agnostic so that OEM's can configure framework as per their requirements. The current proposal is applicable only if HU is AP. I will make changes in proposal as per the Steering Committees' decision on this topic.

ashwink11 on 4 Oct 2019

It was clarified that the following items are still in discussion with regards to this proposal: requiring RPC Message Protection for encryption of WiFi passwords; determining if the head unit or mobile phone should be the network host/access point (AP) or if the transport should remain agnostic as included in SDL 0141. The Steering Committee voted to defer this proposal to allow further discussions and recommendations to be posted to the review issue.

theresalech on 9 Oct 2019

I believe it is also possible to setup a phone to connect to WiFi AP but also maintain its cellular data as well. If possible on head units, it would allow for the internet connectivity the user expects while allowing things such as video streaming over the car's network. https://discussions.apple.com/thread/6448960

BrettyWhite on 10 Oct 2019

The project maintainer has met and debated the different approaches to find a solution that could work for everyone. We have come up with something that is more than what was asked, but after discussing it the solution seems pretty sound and adaptable.

Require Encryption for Password RPCs

The first change we'd like to see is a new keyword added to the RPC spec to enforce encryption rules. This would be requiresEncryption=true|false. The default value would be false if the keyword is omitted. This would help prevent having to add the keyword to all existing RPC definitions.

This would then be added to the request in the author's proposal:

<function name="GetWiFiStatusInfo" functionID="GetWiFiStatusInfoID" messagetype="request" requiresEncryption="true" since="X.X">

However as described later in this comment, that RPC will be removed and a new one added. The RPC that will need the encryption keyword will be the new JoinNetwork RPC:

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="request" requiresEncryption ="true" since="X.X">

Make feature for OEM apps only

The process for app developers to go through to enable this type of feature seems to be pretty high. There's also a good chance app developers don't properly integrate the feature and cause it to be unstable. Since Core can only know so much about the app's abilities, the flow has a high probability to fail in production. By limiting this RPC to an OEM app or apps, OEMs can ensure the feature works reliably.

There is also a new preference supplied that will include a user's preference to data usage that will have syncing requirements which are best kept to the minimum participants possible.

Enable both Head Unit and Mobile devices to be Access Points

We appreciate the pros and cons list @ashwink11 put together on having the access point be one or the other. Looking at everything it seems as though there is not a clear, single choice due each scenario having specific advantages/disadvantages. Therefore, we tried to modify the solution to enable both situations. This will require some changes to the RPCs in the proposal, but fairly simple modifications.

At a high level the flow is as follows:

App sends RegisterAppInterface with new NetworkingAbilities param.
Head unit uses info supplied in NetworkingAbilities to determine best network setup.
Head unit sends RegisterAppInterface response with the determined network setup and actions.
The network is set up and joined.
1. If Head unit should be network host:
  1. Head unit requests HMI sets up a WiFi network (needs new request/response not yet determined)
  2. HMI sets up network, sends OnWiFiNetworkStatusUpdate (formerly OnWiFiTransportStatusUpdate)
  3. Once the notification is received by Core, it will send a JoinNetwork request (formerly an OnSystemRequest notification) that contains the information to join the network.
  4. When the OEM app receives the JoinNetwork request, it will attempt to join the network. It will send the success or failure information in the response.
    1. If the OEM app is running is on iOS device, it may be required to put the app into the foreground to join the network programmatically. This will require HMI flows to be created to prompt the user to do so.
2. If the mobile device is selected to be the network host:
  1. The OEM app will receive the RegisterAppInterface response with the info that it is to host the network.
  2. OEM app sets up "hot spot" WiFi network.
  3. Once network is up and running, app sends JoinNetwork request that contains the information to join the network to the head unit.
  4. When the head unit receives the JoinNetwork request, it will attempt to join the network (likely through the HMI, new RPC needed).It will send the success or failure information in the response.
Core then sends the TransportEventUpdate protocol message with IP and port to connect the TCP transport to all appropriate apps. Flow is then as defined in previous secondary transport proposal.

First, we expand the information provided in the RegisterAppInterface request and response:

 <struct name="DeviceInfo" since="3.0">
 ...

    <param name="wifiConfigurationInfo" type="WiFiConfigurationInfo" mandatory="false">
            <description>Device's available configurations around WiFi networking</description>
    </param>
 </struct>

New struct WiFiConfigurationInfo and supporting Enums:

<struct name="WiFiConfigurationInfo since="x.x">
    <description>Describes some of the sending device's available configurations around WiFi networking. This includes the ability to automatically join a network or host one itself.</description>

    <param name="autoJoinWiFiSupported" type="Boolean" mandatory="false">
        <description> </description>
    </param>

    <param name="canHostWiFiNetwork" type="Boolean" mandatory="false">
        <description> </description>
    </param>    

    <param name="dataFallbackSupported" type="Boolean" mandatory="false">
        <description> This describes the devices ability to support joining multiple networks and using one for internet connectivity if the not available on a different, connected network.</description>
    </param>     

    <param name="dataUsagePreference" type="Device" mandatory="false">
        <description> This describe the preference of what data to use. This is useful when a user might have unlimited data on one device but a cap on another</description>
    </param> 

    <param name="wifiFrequencyBandsSupported" type="" array="true" minSize="1" maxSize="100" mandatory="false">
        <description> An array of frequencies supported by the device. Values should be in units of GHz for example 2.4GHz, 5.0GHz, etc </description>
    </param> 
    <param name="wifiSpecsSupported" type="Integer" array="true" minSize="1" maxSize="100" mandatory="false">
         <description> An array of WiFi Specifications, aka "Names", supported by the device. Currently expected values should be from the following: 802.11b = 1, 802.11a = 2, 802.11g = 3, 802.11n = 4, 802.11ac = 5, 802.11ax = 6.  </description>
    </param> 

</struct>

<enum name="FrequencyBand" since="x.x">
    <element name="2_4_GHZ"/>
    <element name="5_0_GHZ"/>
    <element name="6_0_GHZ"/>
</enum>

<enum name="Device" since="x.x">
    <element name="MOBILE"/>
    <element name="VEHICLE"/>
</enum>

Next we add a param in the RegisterAppInterface response:

 <function name="RegisterAppInterface" functionID="RegisterAppInterfaceID" messagetype="response" since="1.0">
     ...

     <param name="networkingInfo" type="NetworkingInfo" mandatory="false">
         <description>Describes the abilities of the head unit as well as who should host a network</description>
    </param>

</function>

<struct name "NetworkingInfo since="x.x">
    <description>Describes the abilities of the head unit as well as who should host a network</description>

     <param name="wifiConfiguration" type="WiFiConfigurationInfo" mandatory="false">
         <description>Device's ability around networking</description>
    </param>

    <param name="networkHost" type="Device" mandatory="false">
        <description> This describe which device is to host the common network that should be joined. The device listed here should immediately start their network.</description>
    </param> 
</struct>

Join Network RPC

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="request" requiresEncryption ="true" since="X.X">
    <description>A request for the receiver to join the specified network.</description>
    <param name="wifiState" type="WiFiStateInfo" mandatory="false">
        <description>wifi state info</description>
    </param>
    <param name="ssid" type="String" minlength="1" maxlength="32" mandatory="false">
        <description>name of the WiFi ssid</description>
    </param>
    <param name="password" type="String" minlength="1" maxlength="100" mandatory="false">
        <description>password to use to connect AP</description>
    </param>
    <param name="securityType" type="WiFiSecurityType" mandatory="false">
        <description>security type of WiFi AP</description>
    </param>   
</function>

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="response" since="X.X">
    <description>A response and description of requested action.</description>
  <param name="success" type="Boolean" platform="documentation" mandatory="true">
    <description> true, if successful; false, if failed </description>
  </param>

  <param name="resultCode" type="Result" platform="documentation" mandatory="true">
    <description>See Result</description>
    <element name="SUCCESS"/>
    <element name="UNSUPPORTED_RESOURCE">
    <element name="DISALLOWED"/>
    <element name="REJECTED">
    <element name="TOO_MANY_PENDING_REQUESTS"/>
    <element name="APPLICATION_NOT_REGISTERED"/>
    <element name="GENERIC_ERROR"/>
    <element name="USER_DISALLOWED"/>
    <element name="DATA_NOT_AVAILABLE"/>
  </param>

  <param name="info" type="String" maxlength="1000" mandatory="false" platform="documentation">
    <description>Provides additional human readable info regarding the result.</description>
  </param>   
</function>

Determining which device should host the network

Once the head unit receives the RegisterAppInterface and the WiFiConfigurationInfo it must decide who should host. Each bullet point assumes that the network configurations can be supported by both devices (frequencies, data fallback, etc).

If a dataUsagePreference is supplied, the head unit will use this preference.
If autoJoinWiFiSupported is set to true and canHostWiFiNetwork is set to false ,the head unit will host.
If autoJoinWiFiSupported is set to false and canHostWiFiNetwork is set to true, the mobile device will host.
If dataFallback is set to false and the head unit does not have internet access or the head unit has reached its cap, the mobile device will host.
If both autoJoinWiFiSupported and canHostWiFiNetwork are set to true, the head unit will host.
If the mobile device doesn't supply enough information to rule out that it can connect to a WiFi network hosted by the head unit, the head unit will host the network.

joeygrover on 11 Oct 2019

👍1

The Steering Committee voted to return this proposal for revisions. The author will revise the proposal to follow the approach described in this comment from the Project Maintainer.

theresalech on 16 Oct 2019

During the 2019-10-29 Steering Committee meeting, the author requested that this proposal be brought back into review so they can voice concerns about the previously agreed upon revisions. The Steering Committee first voted that it was acceptable to move a proposal from a Returned for Revisions state to an In Review state without the previously agreed upon revisions being performed, and then voted to move this particular proposal back into review. It was noted that a move like this within the Evolution Process has not happened before, and should not become standard practice. It was also clarified that as the Steering Committee previously voted to return this proposal for revisions, it will be the author's responsibility to speak to their concerns and provide suggestions for next steps.

theresalech on 30 Oct 2019

Concern 1: Require Encryption for Password RPCs
“requiresEncryption” attribute in RPC definition

Encryption of RPCs is already described in SDL-0207. If an OEM desires a secured channel for any particular RPC, they can use policies to enforce it.
The proposed attributes override the OEM decision if the encryption of this RPC is not desired. The consequence is the need for security libraries form every OEM integrating SDL.

Concern 2: Make feature for OEM apps only
There are APIs proposed that would enable-disable the use of this feature. If App developers enable this feature, they would just need to add Android/iOS permissions to use Wi-Fi APIs. If app developers do not want to add Android/iOS permissions, they can disable this feature.

Concern 3: Enable both Head Unit and Mobile devices to be Access Points
We see a few issues in implementation on reviewing this suggestion. Run time decision to use Wi-Fi mode has some disadvantages.

IVI would need to support both Wi-Fi AP and Wi-Fi station mode. Adding more implementation and maintenance efforts for IVI.
IVI may have some other features using the Wi-Fi access point. In such scenarios, IVI in the Wi-Fi station mode cannot be used at all.
Switch between Wi-Fi access points to Wi-Fi station mode could introduce delays in accessing apps that would require it.
Mobile device access point abilities are probably very limited to create programmatically. iPhones cannot create Wi-Fi access point programmatically.

Comparison on the basis Wi-Fi roles and internet connectivity

I think for users, it would be easier to use the Wi-Fi feature if IVI is an access point. There could be other features as well, which would be using IVI Wi-Fi AP and it would be difficult for SDL adapters to implement and manage both Wi-Fi modes in IVI for apps.

ashwink11 on 30 Oct 2019

_EDIT:_ Minor wording and grammar updates.

1.1. The difference is that policies can be turned off by any given OEM. The addition to the RPC spec _requires_ all OEMs to enforce this by hardcoding it into Core.

1.2. Yes and no. Yes, the point of this requirement is that all OEMs _who want to support WiFi password sharing_ have to support and integrate encryption because it is _wrong_ of them to not do so. That's why the decision was to require it at this level. But no, it's not required of all OEMs implementing SDL; it is only required for those who choose to support WiFi password sharing.

2. There are several reasons the decision was made to require this. First, the burden on 3rd party OEM apps to support this which is _not_, as you say "they would just need to add Android/iOS permissions to use Wi-Fi APIs." That is not true; on the iOS-side they also need to request these permissions of Apple and give their use-cases. This is a burden on the app developer.

Second, if we don't restrict it only to OEM apps, then some apps will have this support but the majority will not, but (at least on iOS) the app must be in the foreground to support it. This means that the head unit will need to signal the phone to bring that app to the foreground or tell the user to bring it to the foreground before requesting. This is easier if there's a single app that the HU knows supports it, and greatly diminishes any advantage of having multiple apps support the feature.

Third, opening it up to third parties opens security concerns since developers would be able to pull the Wi-Fi password after it has been decrypted (or, on your scheme, just pull the decrypted password at any point).

Fourth, opening it up to third parties restricts abilities of the OEM app to have special settings and configurations for this feature since those won't be shared with other third-party apps.

3.1. This isn't true. Perhaps it was not made clear in the revision, but the head unit can support one, the other, or both schemes by altering what it responds with in the RAIR.

3.2. See 3.1

3.3. This point is speculative, and besides, I can't imagine those delays would be prohibitive for accepting this feature. Also, see 3.1 if such a situation is prohibitive for an OEM.

3.4. This is also related to 3.1 and was mitigated in the design. If an OEM only supports the mobile device being an access point, then they won't be able to support iPhones. If they only support the head unit being the AP, then they may leave out some Android users who would otherwise be able to use the system. That's why the design specified supports both, or if the OEM chooses, one or the other. They would specify this in the RegisterAppInterfaceResponse.networkingInfo.wifiConfigurationInfo parameter.

joeljfischer on 5 Nov 2019

👍1

Stand in for Ashwin as the PM reply came in very late.

1.1. We understand the result of the attribute flag. The point is that we don't agree to enforce encryption. After consulting the Ford cyber security team we don't need encryption on wired transports and we see benefits with a use case of apps connecting over USB without including the security library.

1.2. I'm not sure if we can say _wrong_ From your standpoint you feel that WiFi credentials must be encrypted under all circumstances. We disagree to this and we see your requirement to be fulfilled with SDL-0207. See 1.1. about wired communication and Ford decision that encryption is not required.

Just for completeness: I don't think I can speak to this point. I would appreciate the author or other Ford members involved in the discussion to get a change to respond.

3.1. It is very true what Ashwin wrote. Changing the role at runtime results in high stress to the WiFi firmware. Our experience is that the firmware can malfunction especially when changing the mode. Adding role change to IVI for SDL is complex, comes with high cost and the risk of issues is really high. Therefore Ford would probably enforce AP mode only. Other IVIs may be STA only resulting in a cluttered setup making it potentially difficult to sell this feature as a big gain. I think we should decide on one mode highly suggesting IVI at AP mode.

3.2. Determining which device should host the network breaks with Ashwin's argument. If the OEM has a demand to keep the IVI in one state (e.g. AP mode for offering WiFi hotspot) then there is no reason to try to determine. I'm afraid we are making assumptions per mobile OS and all I want to say is that SDL apps are not of highest priority when deciding on IVIs WiFi mode.

3.3. Resuming a mobile navigation app over WiFi after an ignition cycle can be impossible with role changes.

3.4. @joeljfischer I don't think this statement is acceptable. See 3.1. where I mentioned possible cluttered setup across IVIs and OEMs. I think what Ashwin tries to say is that creating a mobile hotspot programmatically requires many changes to the mobile API and it increases IVI complexity and risk to break with WiFi solutions. iOS won't support this feature. This is no evidence but a concern that Android might break the ability which would be severe to the feature. We don't expect this risk with IVI being the AP.

3.5. I want to add a concern to the data usage preference. In Europe unlimited data contracts are very rare or very expensive. I don't believe it'll change in the next couple years expecting that all European SDL users would not accept phone data usage as a preference. There must be requirements that IVI avoids data consumption if IVI connected to phones WiFi due to SDL. Otherwise the data traffic can be out of control having IVI downloading software updates...

3.6. I want to add another security related issue of vulnerability. If the mobile device becomes the AP it'll be subject of attacks. Depending on the phone attacks such as KRACK might still be possible.

kshala-ford on 5 Nov 2019

Regarding second concern:
2.
First, as already mentioned, I never said all app developers need to implement this feature. If App developers think that it would be a burden for them to implement this, they can skip it.
App developers can take a decision about whether they want to implement this feature or not.

Secondly, if only the OEM app can support this feature, the user would need to always use the OEM app first to use the mobile navigation or projection app. The user path would be for the iPhone device is:
a. Launch OEM App
b. Accept user consent to connect Wi-Fi
c. Launch Mobile Navigation App or projection app

In case, the Wi-Fi connection is lost for some reason, the user would need to repeat the above-mentioned steps.

It would be a lot easier if App which needs Wi-Fi connections initiates it. The user would not need to follow extra steps to connect to Wi-Fi. If an app which requires Wi-Fi initiates connections, user flow would be:
a. Launch Mobile Navigation App or projection app (please refer proposal for details )
b. Accept user consent to connect Wi-Fi

Third, already discussed in point 1. OEM can use encrypted service using SDL-0207

opening it up to third parties restricts abilities of the OEM app to have special settings and configurations for this feature since those won't be shared with other third-party apps.

Fourth, please do let us know which special settings and configurations are you referring too.

In addition, if any OEM does not want third party apps to use this feature with their SDL enabled IVI system, they can do so by blocking access to RPCs used to share Wi-Fi credentials using policies(refer proposal for RPC and policy functional group details).

Edit: Added the last point.

ashwink11 on 6 Nov 2019

During the 2019-11-05 meeting, the Steering Committee voted to keep this proposal in review until our next meeting, to allow the author time to respond to the comments from the Project Maintainer, and to allow all members to review the items still under discussion.

It was clarified that the 3 questions that members need to answer, and should be prepared to answer next week, are:

Should WiFi credentials always be forced to be encrypted?
- Always encrypted
- Allow OEMs to decide for themselves
Should WiFi auto join/network creation be reserved for OEM apps only, or should we add the feature for all app partners?
- OEM apps only
- All SDL apps
Who should be allowed to be the network host/access point?
- IVI
- Mobile phone
- Both
- Neither; this should not be defined by SDL

theresalech on 6 Nov 2019

The Steering Committee voted (17 out of 27 votes) to keep this proposal in review until our next meeting on 2019-11-19. It was emphasized that all members should review this proposal prior to our next meeting and join the meeting prepared to vote on the 3 open items included in this comment.

theresalech on 13 Nov 2019

We understand the length of this GitHub issue makes it difficult to follow. We try to summarize the Ford position to the list shared by the PM:

Should WiFi credentials always be forced to be encrypted?
- Always encrypted by adding requiresEncryption flag and overriding OEM decisions
- Allow OEMs to decide for themselves by using existing RPC Message Protection
Should WiFi auto join/network creation be reserved for OEM apps only, or should we add the feature for all app partners?
- OEM apps only which affects UX as interaction with two apps is required
- All SDL apps _that require WiFi_ helps UX with the cost of implementing the feature per app
Who should be allowed to be the network host/access point?
- IVI supports most devices incl. iPhone. Some Android devices may require user action to enable cellular connection
- Mobile phone excludes all iPhones from auto connect. IVI must respect phone AP and avoid cellular traffic
- Both Adds a lot to SDL APIs. Very complex for IVI to implement. Risk of failure in role switching. OEM may choose to support only one role
- Neither; this should not be defined by SDL

kshala-ford on 18 Nov 2019

The Steering Committee voted to return this proposal for the following revisions:

WiFi credentials should not always be forced to be encrypted. It will be up to the OEM to decide on encryption.
WiFi auto join/network creation is a feature that can be used for all SDL app partners that use the feature.
Both the IVI and Mobile Phone should be allowed to be the network host/access point. OEMs will only need to support one if desired.

theresalech on 20 Nov 2019

The author has revised this proposal per the Steering Committee's request, and the revised proposal is now under Steering Committee review. This review will take place until January 21, 2020.

theresalech on 15 Jan 2020

1. You note:

If secondaryTransports is TCP_WIFI_AP_MODE, then the WiFi network can be established with the mobile device as the WiFi access point and the IVI can connect using WiFi station mode.

I believe this should state "using WiFi access point mode"?

2. In HMI API changes, you write:

If DeviceInfo.wifiConfigurationInfo.autoJoinWiFiSupported is true and the supported secondary transport is WIFI_STA_MODE, then the WiFi configuration of the IVI and the app are compatible for automatic WiFi connection.

and

If DeviceInfo.wifiConfigurationInfo.canHostWiFiNetwork is true and the supported secondary transport is WIFI_AP_MODE, then the WiFi configuration of the IVI and the app are compatible for automatic WiFi connection.

I think those may be reversed? If Core is in AP mode, the app's DeviceInfo should support that it can join the network and visa versa, which seems to be the opposite of what you've written above.

3. There's no information about _which_ app (if multiple apps support connection) will receive it the notification, nor that the app presenting this information needs to be in the foreground on iOS and how the HMI should make that determination and send the information (this needs information to show that it's possible and to make HMI recommendations).

4. Many of the flows are in the Impact on Existing Code section but should be in the Proposed Solution section, but some notes are in the Proposed Solution. It gets very confusing, very fast. Flow charts would be very helpful including: HMI, Core, and App Library, for each platform and use-case, along with what data is sent between them and what information needs to be gathered internally (e.g. Android and iOS need to generate their DeviceInfo structs.)

5. Creating the DeviceInfo struct on Android may be difficult based on the various versions and manufacturers. Stating how to gather this information and what the parameters should be set as on iOS and Android would ensure that this proposal is possible as it stands.

6. Your version of WifiConfigurationInfo doesn't contain much of the information Joey noted above. We believe that information is important for the module to make an informed decision about whether or not the device can / should support the two modes.

7. Impact on Existing Code -> Proxy Changes -> 2 should not just provide java suite example code, but the actual public APIs that will be used.

8. Impact on Existing Code -> Recommended Use Case Flow -> 2 states:

HMI does not allow video streaming apps to use cases using primary transport.

This sentence isn't making sense to me, could you clarify it?

9. B -> Exception 2 isn't clear. Does the popup appear immediately and disappear after 5 seconds? Does it appear after 5 seconds? If the former, this could be confusing since the device is in the process of connecting.

10. Are the exception strings required for HMI integrators or recommendations. The proposal isn't clear.

11. Under Additional Queries if IVI is a WiFi access point -> 1, you mention that the credentials should be sent even if it's already connected so that it could reconnect. First, the OS will store the credentials so I believe that this is unnecessary. Second, this requires that the app library store the unencrypted wifi credentials within the app. This proposal needs to give a way to store these credentials.

12. The "Alternatives Considered" section should provide the alternatives that were proposed by the project maintainers but rejected by the SDLC steering committee for reference (RPC encryption required for this feature on WiFi-credentials, and OEM-app only support for this feature).

joeljfischer on 17 Jan 2020

Sure, I will include it.
Please refer table for transport type string from proposal here

If TCP_WIFI_AP_MODE, TCP connection over WiFi and the phone is the WiFi access point. So, IVI will connect in the Station mode.
If TCP_WIFI_STA_MODE, TCP connection over WiFi and the phone connects using WiFi Station mode. So, IVI will be in access point mode.

The nomenclature is inline with what was defined for other transports. If IAP_USB_HOST_MODE, iAP over USB, and the phone is running as a USB host.
The transport mode here refers to the mode used by the mobile device to establish connection.

So, the statements you referred from proposals are correct.

If the IVI is in AP mode, then the transport string is WIFI_STA_MODE. The mobile device will use WiFi station mode for connection and the apps needs to send autoJoinWiFiSupported = true, to be compatible for Wi-Fi automatic connection.

I did mention that here: _"This notification will be sent only when a user has provided consent to share WiFi credentials, and the connected app has supported WiFi configuration and the user attempts to launch that app_".
This was also mentioned in the recommended HMI use case flow scenario description here
and here

So, even if there are multiple apps, the notification will be sent to the app only when a user tries to launch it.

Probably you are referring to Impact on Existing Code -> Proxy Changes.

To describe the behavior of the proposed solution in detail for proxy, I defined example APIs and how they would behave in a different configurations. These include the behaviour of proxy when the app developer sets some configuration, which may not be supported at run time.
For example, WiFi transport APIs are not supported by the platform, but enabled by developers. And, how WiFi configuration information is communicated to IVI using RAI.

However, project maintainers can decide on the naming and design of these APIs, hence these points were not included in the proposed solution.
These example APIs are used just to describe the proposal in detail. Please do let me know if it still needs to be moved to the proposed solution.

WiFi transport APIs are available in Android since API level 1. There are some changes from API level 29. I included connection methods for both in the sample code. Also, the API level can be checked using Build version codes, which has been used already in Android proxy.

Can you please clarify which information in Device Info you find it difficult to get in Android?

This proposal does support two Wi-Fi modes and the supported modes are communicated to the mobile apps using the Start Service ACK frame. Please refer section Define Supported WiFi Modes

In iOS, creating a Wi-Fi access point programmatically is not supported. To connect in WiFi station mode, we need only SSID, password and security type.
In Android, both for creating AP or connecting to Wi-Fi we need at least SSID, password and security type.

Regarding additional info in WiFiConfiguration Struct, unfortunately, there was not much info provided on how those attributes will be used and its use cases. Can you please clarify why do we need this info?
Another query is: Is there any SDL integrator who would need it now?

I would suggest adding additional information as they are needed, just want to avoid adding stuff, which might not be used by anyone. Also, if this information is required later, we can add it later.

I wanted to keep that open for Project maintainers, as they are the architect of the proxy, they would know best how to name an API and where to place it.
But, if you want this to be included in the proposal, can you please suggest the name and class for these APIs for both Android and iPhone?
Apologies for the type, correct statement would be: "HMI does not allow video streaming apps use cases using primary transport."
The statement is a precondition for the described use cases. It means the IVI does not allow video streaming on primary transport.
The pop up is shown immediately after the user attempts to launch an App.
Everything in section Recommended use case flow is _recommended not required_.
The pop-up messages are examples and are added as per your suggestions from here.

HMI integrator can have their own pop-up strings.
The first query is applicable only for proxy.
If an App already connected to Wi-Fi and use RPC to share Wi-Fi credentials, it should be allowed. I did not say, it should store it.

The second query is applicable to only the SDL core. Probably this is not clear.
SDL core can store Wi-Fi credentials in the cache, and share with the app using RPCs defined above if all constraints are met. I can add additional text if required.

Sure, I will add these two topics in alternative considered.

ashwink11 on 20 Jan 2020

Was the param NetworkingInfo in the RegisterAppInterface response and agreed upon revision? I don't see that parameter mentioned in the proposal or any changes related to using RegisterAppInterface in the initial access point negotiation.
The Mobile API changes section description only mentions details for when the IVI is the access point. Is this the only description of the mobile device as AP?:

If the IVI is connecting in WiFi station mode and the SDL app can host the WiFi network, the mobile proxy can send JoinWiFiNetwork RPC to the IVI to share the mobile device's WiFi access point credentials.

Was it an agreed upon revision that RPC JoinNetwork would replace the OnSystemRequest usage for this feature?

Once the notification is received by Core, it will send a JoinNetwork request (formerly an OnSystemRequest notification) that contains the information to join the network.

Have we ever discussed what happens if a user disables/enables wifi on their mobile device after an app has already registered?

JackLivio on 20 Jan 2020

As sugggested by project maintainers, Struct NetworkingInfo has two attributes, WiFiconfiguration and network Host. The WiFiConfiguration is also added in DeviceInfo Struct.

In current SDL implementation for Wi-Fi transport, supported transport is communicated with mobile proxy using control frame message.
We propose to use the same for supported WiFi transport modes. Hence, we do not need "NetworkHost" attribute defined in "NetworkInfo".
So, Struct "NetworkingInfo" would have only one attribute which is used by mobile proxy i.e. WiFi Configuration. Since, WiFiConfiguration info also added in DeviceInfo, IVI would know the supported configuration on mobile device and hence act accordingly.
Therefore, I do not see any reason to add WiFiConfiguration in RAI as well.

Please do let me know if you see any limitations with current proposal.

14.

Please refer section Proxy changes. Mobile API changes are described further in detail in Proxy changes section with example APIs.
Please also refer point 7 discussed above.

The suggestions from project maintainers does not discuss a case of multiple apps supporting automatic Wi-Fi connection.
In such scenarios, where multiple apps support Wi-Fi automatic connection, we need a way to select an App that would initiate this Wi-Fi connection.
Thus, we propose that IVI sends System request to an app to initiate Wi-Fi connection either in access point mode or station mode.

I found that both iOS and android device reconnects if we disable and then re-enable Wi-Fi on mobile device. Please do let me know if you have different observation.

ashwink11 on 21 Jan 2020

Thank you for updating the proposal. I appreciate you including many of the different scenarios that must be covered by such a proposal as it will help many of the OEMs integrating into their system understand the requirements.

2. I believe there is some confusion with adding secondary transports to define WiFi networking access and roles. The IAP transport definitions relate to client/server relationship for that specific transport. For TCP_WIFI it is considered the mobile device is always the client. Since the TCP transport can operate regardless of network infrastructure, that information is best suited to be moved to a new tag, eg networkWifiMode or similar. Logic already provided could still be used for this new tag. If the tag is not included or is empty, the feature is not supported, if one is included that is the only mode supported. It could be an array with an ordered list so that if the IVI supports both, the mobile device could be informed and make a decision based on the priority and ability of the mobile device. However, this goes back to point # 13 that this should have been included in the NetworkInfo

11. Agree with Joel here, there should be no need to reconnect and in fact it would create a lot of overhead for apps that are already using the connected WiFi network. At the very least, there should be some flag that requests the reconnection instead of simply stating that every RPC reception would trigger a reconnection for the WiFi network.

13. Yes. It was agreed upon in the first and second vote for the revisions to this proposal and should be included. I believe the author should follow the agreed upon changes, or provide rationale for why it was changed. Is there a benefit to how this was changed? Does it improve performance? Flow? Since the auto connection does not happen until the app is launched I don't see how adding the information to the StartServiceAck vs RegisterAppInterface params would be improved.

15. The JoinNetwork RPC was specifically for this case and could still be sent to a selected application. Apps are able to receive requests from Core and respond accordingly. This lets the module know if the request was successful or not. I think this might have been a missed capability. Therefore, the agreed upon JoinNetwork RPC should be used as stated in the agreed upon revisions.

17. A minor item, all references to Start Service ACK should be StartServiceACK

18. HMI will not send OnSystemRequest notification with RequestType as WIFI_CONNECTION_REQ if app is already connected using WiFi. How will the module know this? Is this a requirement of the RPC Spec then? Also please refer to item # 15 when making potential revisions.

19. I would like see more information in the Potential downsides section. While the added complexity isn't seen as a deterrent because the user experience would be improved, it should be clear that app developers might not feel the same way. Apps are very weary to include added permissions into their app if they don't feel it is necessary. With the ability for "any" app to do this, it is possible no app will do it because they think some other app will handle it. If this is the case, the feature will go unused but will still add technical debt from the required maintenance. I don't believe this will be a likely scenario, but should be included as a potential downside.

20.

If a mobile device is a WiFi access point, SDL Core will not cache WiFi credentials received from a mobile device.

If this is the case, how will the HMI know not to reconnect to a WiFi network when a second app sends the same network info?

21.

The new functional group should be created so that, if required, the user can explicitly disable the sharing of WiFi info.

I assume this will then require a new consumer friendly message describing the permission to be granted, can the author provide this in the proposal? Obviously OEMs can create their own messages, but the default PT will need to supply a sample message by default.

22. I'm not sure I understand how Alternative # 1 is an alternative. Are you just saying it's possible the mobile devices could just check the network status before attempting to connect TCP? I don't think that would be correct as there is no defining requirement that states the TCP connection _MUST_ be on the same local network. It could theoretically be a public IP that is accessible via a WAN connection.

23. While the Javascript Suite is likely not ever going to be able to use this feature, it is still an impacted platform due to new RPCs being added. In order to in compliance with the RPC spec all RPCs must be included and able to be responded to.

EDIT: I started at 16 improperly. I moved my old # 16 to # 23.

joeygrover on 21 Jan 2020

Sequence diagram if IVI is Wi-Fi access point
ivi_ap

Description of Sequence diagram if IVI is Wi-Fi access point

An SDL App registers on IVI. This app supports WiFi automatic connection and hence sends DeviceInfo.wifiConfigurationInfo.autoJoinWiFiSupported = true.
IVI shares Wi-Fi access point info with SDL core using OnWiFiTransportStatusUpdate notification.
The user attempts to launch an SDL app that supports WiFi automatic connection.
IVI sends System request with request type WIFI_CONNECTION_REQ to SDL core and which is then forwarded to the proxy.
The proxy sends GetWiFiNetworkInfo to get WiFi SSID, password and security type.
The proxy connects to Wi-Fi using APIs provided by platform APIs.

Sequence diagram if Mobile device is Wi-Fi access point

mobile_ap

Description of Sequence diagram if the mobile device is a Wi-Fi access point

An SDL App registers on IVI. This app supports WiFi automatic connection and can host network. Hence, it sends DeviceInfo.wifiConfigurationInfo.canHostWiFiNetwork = true.
The user attempts to launch an SDL app that supports WiFi automatic connection.
IVI sends System request with request type WIFI_CONNECTION_REQ to SDL core and which is then forwarded to the proxy.
The proxy sends JoinWiFiNetwork to SDL Core. SDL core forwards this RPC to IVI.
The IVI connects to Wi-Fi using credentials provided in JoinNetwork RPC.

Edit: added descriptions

ashwink11 on 21 Jan 2020

& 13.

Rationale for using StartServiceAck instead of RAI:

In the current implementation of SDL, we already have control frame messages to communicate supported transport. To use the same control message frame structure we just need to define two new transport string. If we use StartServiceAck, we do not need to define any new Struct or add a new parameter in the register app interface response. We want to avoid adding any additional params in the Register app interface response, as it already has lots of parameters.
In addition, until now, all supported transport strings and its modes/profile/protocols used for audio/video services are defined in StartServiceAck.
I believe Wi-Fi modes should also be defined for StartServiceAck transport types as secondary transport is used only for audio/video services.

If we use RAI and new structs, we would have to define a new configuration in the smartdevicelink.ini file for supported Wi-Fi transport modes. This is required in scenarios where IVI just wants to support only one Wi-Fi configuration, either Wi-Fi access point mode or Wi-Fi station mode. This SDL configuration would mean new implementation in SDL core which can be avoided if we use StartServiceAck.

Hence, to keep SDL core changes to minimal, I propose to use StartServiceAck.

Regarding naming of transport type strings

As we can see in available transport type strings, the names of the transport and its attributes are combined. The attributes used can be SPP for Bluetooth, protocols like IAP/AOA or transfer modes in USB.
All these transports and their attributes do not necessarily relate to the client/server relationship.
For example:

Similarly, I propose to add two new transport strings as well for Wi-Fi.

and the name of the transport type is suggested depending on the role of the mobile device.

If we use the transport type strings as defined above, I do not think we need to add a new tag to include transport modes. We kept TCP_WIFI transport type as it is to support backward compatibility.

Agreed. I will remove this point.
We need to use System request in scenarios where multiple apps support Wi-Fi automatic connection feature. We do not want all supporting apps to try connecting to Wi-Fi or try creating a Wi-Fi access point. Hence, system request will be used to just provide an indication to apps, that they can try connecting Wi-Fi.

Join Network RPC is defined and still used as suggested. Please refer to the sequence diagram and its description in the above comment for details.

Sure, I will add it.
An app is supposed to send control frame message Register Secondary Transport over secondary transport. Also, this information is provided to HMI using secondaryDeviceInfo in Struct HMIApplication. The change in HMIApplication is notified using BasicCommunication.UpdateAppList. This is defined in the proposal SDL-0141.

Using this information, the IVI would know, if the App is connected using secondary transport or not. Hence, it can check whether the system request needs to be sent or not.

Sure, I will add the following sentence in potential downside: Apps are may not include added permissions into their app if they don't feel it is necessary. If these permissions are not added, apps will not be able to use this feature.
If a Wi-Fi connection is available, all video streamings apps will register themselves using "Register Secondary Transport".
As described in point 18, if the app is already connected using secondary transport, it will never receive System request with request type WIFI_CONNECTION_REQ.
The proxy will not send JoinNetwork RPC if it does not receives system requests with request type WIFI_CONNECTION_REQ.
I can suggest the following text. Please do let me know if this is Ok.
An app can access vehicle Wi-Fi. These permissions would allow the app to connect to your vehicle Wi-Fi automatically.
This alternative is regarding app permissions to use Wi-Fi transport APIs provided by the platform. To check the current Wi-Fi connection (for example Wi-Fi SSID) in the mobile devices, an App needs extra iOS entitlements.
However, if the mobile device is connected to a certain WiFi access point and an app tries to connect to the same access point, the platform APIs will just return errors.

So, there was discussion previously whether to check for the current Wi-Fi connection before the mobile device attempts a connection to the IVI access point. If proxy checks for current Wi-Fi connection, it would need extra permissions and hence to minimize the number of iOS entitlements an App needs to request, it was decided that the proxy will rely on error messages instead of checking current Wi-Fi connection.
Please refer point 6 from comment here and here.

I will get back to you on this point.

ashwink11 on 22 Jan 2020

We define two new RPCs in this proposal and both of them have a response.
If you are referring to System Request notifications, it will be sent, only when WiFiConfiguration info is sent to IVI.

I added a table to track concerns. Please do update it.

@joeljfischer @JackLivio @joeygrover
I hope we can close concerns: 3,9,10,14,15,16,18,20,22 as no changes required. Please confirm.

ashwink11 on 22 Jan 2020

During the 2020-01-21 Steering Committee meeting, the author presented a sequence diagram that the committee agreed would be a good addition to the proposal. Ultimately, the Steering Committee voted to keep this proposal in review for an additional week, to allow the author time to respond to the comments and for the conversation to continue on the review issue.

theresalech on 22 Jan 2020

3. 👍

4/5. I'm not asking for the naming and design of the internal APIs, but I am asking for information on what and how the Android and iOS libraries are expected to gather the information that will be sent back in the DeviceInfo struct (taking into account version, device type, API availability, etc.). Although the WiFi APIs are available on Android from version 1, I doubt that all devices and manufacturers support AP and station mode. If you're expecting every android device to state that they support both, that should be stated. Are you expecting every iOS device to state it supports AP mode? If so, that should be stated.

6. There's a miscommunication here. I'm not talking about whether the IVI system can support the two modes, I meant the IVIs determination of whether it should attempt a connection of one or the other. That's what the original WifiConfiguartionInfo assisted the HMI in determining. See "Determining which device should host the network" in Joey's comment for the uses of those parameters.

7. The proposal needs to state where these APIs are coming from, it cannot be ambiguous. If the author does not wish to provide the public APIs and leave it up to the maintainer, that's fine, but it must be clearly stated in the proposal.

8. 👍

9. Then I disagree with this verbage. The recommended verbage should be something like "Attempting to connect app to WiFi." If the timeout occurs, then an error message would need to be displayed telling the user what happened and how to fix it based on DD status.

10. Okay

11. I think there's a miscommunication here, but I don't understand your response. I'm saying that first, this is not necessary and should probably be removed from the proposal because the OS stores the password for the WiFi network and will attempt to reconnect using it. Second, if you have good reasons to keep it around (and that use-case should be detailed more clearly), then you need to specify a mechanism for storing this user-sensitive data within the 3rd-party app in a secure way (though we are already giving 3rd-party devs access to the user's wifi password, so perhaps you aren't expecting to store it securely? If not, please still specify the mechanism and why it's okay that it's not secure).

joeljfischer on 22 Jan 2020

@joeljfischer

Regarding 6. I think there's a misunderstanding of the vote from November 19. The vote was for supporting both variants (IVI to be AP or STA) however I can remember that the vote was that the IVI needs to support only one variant as stated by another SDLC member. Either AP or STA should be supported. Ford understanding is that supporting both isn't planned therefore structs like WifiConfigurationInfo isn't needed. The term "if desired" as documented in the minutes was not mentioned in the meeting during the vote.

My suggestion would be to revisit this point in the steering committee meeting to make a clear statement to the vote and that everyone is on the same page. If the feature must support dynamically switching between AP and STA depending on phone capabilities then we understand the need of sharing information e.g. with the suggested struct WifiConfigurationInfo. Otherwise if this dynamic switching is not expected by the vote it'll dramatically reduce the complexity of the feature.

kshala-ford on 23 Jan 2020

4/5.

DeviceInfo struct is already available in the current implementation of SDL. In this proposal, we are adding one additional parameter in this struct and hence, the rest of the implementation will remain the same. I found device info struct implementation here for android and here for iOS proxy.

Can you please clarify why we need to provide details of the device info version, OS, etc in this proposal when it is already implemented?

To add WiFi configuration info, the proxy needs to check WiFi APIs' availability. In iOS and Android SDK there are ways to find out API availability, "__IPHONE_OS_VERSION_MAX_ALLOWED" used in iOS proxy here and "Build.VERSION.SDK_INT" used in android proxy multiple times, reference here.
PM as an architect of the proxy can use the same platform APIs as they used earlier. I do not intend to propose any special ways to find this info.

iPhones cannot create WiFi access point programmatically. If the iPhone is a Wi-Fi access point and IVI is connecting in Wi-Fi station mode, iPhone users would need to connect Wi-Fi manually. I mention this in our previous discussions as well.
Please refer comments here, here and here

This case is included in the proposal as well for cases where the mobile device does not support automatic Wi-Fi connection. Please check the use case E. Automatic WiFi connection cannot be established.

Sure, I will mention this point in proxy changes. "Project maintainers can decide on the API implementation."
I hope the use of example APIs in the proxy changes section to illustrate the behaviour of mobile APIs are fine. Please do let me know, that needs to be removed.
Sure, I will change the phrase from "Waiting for WiFi Connection." to "Attempting to connect the app to WiFi.". The use cases for driver distraction and failure of automatic Wi-Fi connection are already defined in the proposal.
Please check the use case D. Driver distraction is ON and E. Automatic WiFi connection cannot be established
Agreed. I will remove it.

@joeljfischer @JackLivio @joeygrover
I hope we can close concerns: 9,14,15,16,18,20,22 as no changes required. Please confirm.

ashwink11 on 23 Jan 2020

Hi @ashwink11 please find collective responses from the PM below. We've also updated the table to reflect these comments. Thanks!

4/5. We're not asking about how you would populate the DeviceInfoStruct parameters that already exist, but instead how you would populate the new DeviceInfoStruct parameters. We understand that there are version platform checks for API availability, but we're asking for exactly how you expect those to be populated based on version information. The questions are: do you expect every Android device to state that it supports both station and AP mode auto-connectivity? Do you expect every iOS device to state that it supports station auto-connectivity? If so, please state that in the proposal.

6. We're not sure we're clear on what you mean by "dynamic switching." If by that you mean that the head unit can choose, when the first app connects and is setting this up, which type of connection to use based on the device's capabilities, then yes. If you mean that after an app has connected, that it can switch to another way, then no, that's not what we're talking about. We also want to note that it was very clear in that meeting what was meant and agreed to.

Even your own comment says: "Who should be allowed to be the network host/access point?...

Both Adds a lot to SDL APIs. Very complex for IVI to implement. Risk of failure in role switching. OEM may choose to support only one role"

As you noted in your comment, the agreed upon point was for "role-switching", or that the OEM may choose to only support one role. You said the "OEM may choose," while the PM's meeting comments said, "if desired," which means the same thing.

9. "B -> Exception 2" and "E" seem to talk about the same scenario and provide the same solution, therefore E doesn't appear to solve the problem.

2\13. We don't agree that the start service ack control frame is a better solution than using the register app interface response. One could argue the same point that adding the param to the start service ack is unnecessary and crowding the control frame. Reiterating Joey's response: "Since the auto connection does not happen until the app is launched I don't see how adding the information to the StartServiceAck vs RegisterAppInterface params would be improved."

Also we have an issue with tieing the access point information to the secondary transport string in the start service ack's control frame. We feel that this is causing an unnecessary restriction that will prevent using the wifi transport as a primary transport in the future.

14. Our complaint is that of the 7 requirements listed under the mobile api changes, 0 of those points describe when the mobile device is the access point. There were clearly agreed revisions that the mobile device can act as the access point but none of the language in the mobile api changes section describes how the RPCs should act in the case of the Mobile API as the AP, or even the negotiation of which device should be the AP. There might be descriptions in the proxy sections, but changes in the Mobile API still affect SDL Core.

In the original agreed upon revisions described in this comment here, none of these RPC changes are reflected in the Mobile API changes section regarding the mobile device as the access point. (See comments point 4. ii)

15. Reiterating Joey's comment from earlier, as of SDL Core 5.1, Core is able to send requests to the mobile proxy, and the mobile is able to provide a response. By Core sending the JoinNetwork request to mobile, and mobile providing a response, Core is able to know if the request was successful. We believe this is a better solution than using OnSystemRequest which provides no response to Core.

Additionally regarding why OnSystemRequest should not be used, OnSystemRequest is included in the most basic permissions level. Due to the flow being described in number 18, there would be no security method for policies to block the notification from the HMI to request the mobile app connect to the access point since all apps need OnSystemRequest permissions. Every app that is not registered over the WiFi transport would be getting spammed with notifications that they should be connecting to the WiFi AP.

Also we noticed that in your flow charts you have Core sending a SystemRequest to the mobile proxy, when we think you mean OnSystemRequest? Please confirm.

16. We understand that the mobile device will attempt to connect to the WiFi AP on the module again, but we are concerned about how enabling the WiFi transport after app activation will affect the secondary transport connection. Also in the case of the mobile device as the access point, will the head unit be able to auto connect to the mobile's access point? Same question regarding the secondary transport affect applies for the mobile access point.

18. The RegisterSecondaryTransport will not always be sent (app doesn't need it, app uses USB instead, etc) so it can't be counted on as a flag that the network has been joined. It is also not directly related because the secondary transport TCP is not limited to only LAN connections as stated previously. See point 22. The issue is that if the HMI only checks the RST status for the app being activated, it will try this for every app activated. This would cause the IVI system to send an OnSystemRequest to each app on activation, and based on supplied code, disconnect the previously made connection. The IVI system needs to store or be able to check what devices are already connected on its hosted network for IVI as AP. For mobile handset, the IVI needs to check which network it is on before attempting to rejoin. So the question still stands: How does the IVI system know the network has been joined already?

19. We would like to see stronger language and an added point about the lack of enforce encryption:

Apps may not include added permissions into their app if they don't feel the feature is worth the added user ask.
If these permissions are not added, apps will not be able to use this feature.
If no apps add these permissions, the feature will not work at all and will have resulted in unnecessary technical debt.
With no enforced encryption, WiFi passwords will be in plain text and have the potential to be leaked.

20. This is not true because of proposal SDL-0214. The mobile libraries should only register over secondary transports when they are activated. Again, this is relying on the secondary transport as a means of logic which can't be used. See #17 on how to actually handle this.

21. We'd recommend %appName% is requesting the permissions to auto connect to your WiFi network. You can change these permissions and hear detailed descriptions in the mobile apps settings menu. Please press Yes to grant permissions or No to deny.

22. Please see previous points that the TCP secondary transport can work over WAN, and are not limited to LAN connection. However since this is an alternative, we are not going to keep pushing this specific point.

23. The JavaScript is an impacted platform due to RPCs being added. It needs to be added.

24. Based on the discussion around iOS's entitlement requirements, do you have any suggestions about how the PM is to test the APIs created to connect to the IVI WiFi network? The PM will not have the entitlements necessary. Will this work in debug without the entitlements?

edit: added no. 24 to table

theresalech on 24 Jan 2020

With "dynamic switching" I mean the head unit can choose, when the first app connects and is setting this up, which type of connection to use based on the device's capabilities.

Even your own comment says: "Who should be allowed to be the network host/access point?...

I'm sorry but none of my concerns are related to my comment. Whatever I marked bold were concerns to each point and to BOTH the concern was that OEMs could choose to support only one role and therefore risk compatibility with certain apps. Anyways, I'm specifically referring to the SC meeting where we voted on this item which was obviously after my comment. Another SDLC member voted for both but stated that the IVI should be running in AP or Station mode. The PM and I have asked for clarity what this statement exactly means and our understanding was that implementing both roles at the same time (with dynamically switching between STA and AP) into an IVI is not in scope.

Please don't be afraid. I don't want to question the SDLC vote. I'm only looking for clarity. Therefore discussing this item in the SC meeting is what I'm looking for.

kshala-ford on 27 Jan 2020

4/5

Response to Query: Do you expect every Android device to state that it supports both station and AP mode auto-connectivity? Do you expect every iOS device to state that it supports station auto-connectivity?
No, we do not expect that. Auto-connectivity will be enabled provided app developers enabled it and platform supports it.
This is also mentioned in the proposal. Please refer proxy changes section point 2 which describes this in details here

Yes, they are similar however one is applicable when DD is ON and another when mobile devices do not support Wi-Fi automatic connection. In both cases we recommend the user to connect Wi-Fi manually.

2/13.

Regarding the future implementation of Wi-Fi transport as primary transport.
I understand, there are certain restrictions from some mobile platforms and that's why the concept of primary and secondary transport was brought. So, I do not agree about including something that's not possible to implement now. You can always extend this behavior by bringing in new proposals later to support Wi-Fi as primary transport.

Our Rationale for using StartServiceAck instead of RAI:

a. In the current implementation of SDL, we already have control frame messages to communicate supported transport. To use the same control message frame structure we just need to define two new transport string.
b. If we use StartServiceAck, we do not need to define any new Struct or add a new parameter in the register app interface response. We want to avoid adding any additional params in the Register app interface response, as it already has lots of parameters.
c. In addition, until now, all supported transport strings and its modes/profile/protocols used for audio/video services are defined in StartServiceAck. I believe Wi-Fi modes should also be defined for StartServiceAck transport types as secondary transport is used only for audio/video services.
d. If we use RAI and new structs, we would have to define a new configuration in the smartdevicelink.ini file for supported Wi-Fi transport modes. This is required in scenarios where IVI just wants to support only one Wi-Fi configuration, either Wi-Fi access point mode or Wi-Fi station mode. This SDL configuration would mean new implementation in SDL core which can be avoided if we use StartServiceAck.

Can you please clarify which one you do not agree with?

This is not true. I never mentioned that the functional group or DD requirement or onSystemRequest WIFI_CONNECTION_REQ requirement is applicable to only one Wi-Fi mode. DeviceInfo.wifiConfigurationInfo is configuration for both modes.

If any requirement is applicable only in one mode, I mentioned that in requirement. Hence, if the specific Wi-Fi mode is not mentioned requirement, then it is applicable for both.
As mentioned earlier if you could look in the proxy changes section both cases have been discussed in detail.

As stated earlier, Join Network RPC still available and the proxy will receive a response for it in case the mobile device is Wi-Fi AP.
OnSystemRequest is used just as an indication to the proxy to initiate a Wi-Fi connection. IVI does not need to know where this indication was successful or not. We defined RPC to share Wi-Fi details, the core and proxy will have responses for these RPCs.

I do not believe, that the app will be spammed with notifications, please refer to point 3 and point 4 in the HMI API changes section here. Notification is sent when the user tries to launch app only if WiFi configuration of IVI and App is matched. If the user does not launch or Wi-Fi configuration does not match, the app will not get the notification.

Yes, I was referring to OnSystemRequest, the proposal already has reference to OnSystemRequest. I will update the sequence diagram while adding it to the proposal.

Are you referring to establishing a TCP connection if Wi-Fi is disable-enabled on a mobile device? If yes, since, SDL over Wi-Fi transport is already implemented, the behavior of TCP connection via secondary transport during Wi-Fi re-connection depends on existing implementation.

In this proposal, we do not intend to change that behavior. However, if you are asking about Wi-Fi reconnection, as stated before the mobile device connects automatically.

I already mentioned in the proposal that OnSystemRequest is sent only if the following constraints are met.
a. user attempts to launch an App
b. WiFi configuration of an app and IVI are compatible
c. User allowed permissions for Wi-Fi RPCs.
d. HMI will not send OnSystemRequest notification with RequestType as WIFI_CONNECTION_REQ if the app is already connected using WiFi.

Please refer to point 3 and point 4 in the HMI API changes section here. Notification is sent when the user tries to launch app only if WiFi configuration of IVI and App is matched. The compatibility of an App and IVI for automatic Wi-Fi connection is also described herein proposal.

So, RST is not the only thing checked by IVI before sending OnSystemRequest.

19.

Sure, I will add suggested statements in the proposal in potential downsides.

Thank you for referring SDL-0214 proposal. I was not aware of it. In this proposal, I found below statement:

App wishes to start either the video or audio service and Core has indicated that they are preferred to be started on the secondary transport.

I guess, here app would start audio/video service when HMI level changes. So, HMI level change is an indication of an app to establish a Wi-Fi TCP connection. Please confirm.
What would happen if Wi-Fi is not connected? What happens if the mobile device is connected to a different network?
Does the socket connection timeouts?
I guess the HMI level of an App is back to none if the Wi-Fi connection fails.

I will add the suggested string in the proposal for policy changes.

This alternative was not regarding TCP connection. This alternative is regarding app permissions to use Wi-Fi transport APIs provided by the platform. To check the current Wi-Fi connection (for example Wi-Fi SSID) in the mobile devices, an App needs extra iOS entitlements.
So, there was discussion previously whether to check for the current Wi-Fi connection before the mobile device attempts a connection to the IVI access point. If proxy checks for current Wi-Fi connection, it would need extra permissions and hence to minimize the number of iOS entitlements an App needs to request, it was decided that the proxy will rely on error messages instead of checking current Wi-Fi connection.

Ok. I understand that I just need to add JavaScript in the impacted platform field in the header of the proposal. No other changes. Please confirm.
I don't think it would work without entitlements.

Update the table below.

ashwink11 on 27 Jan 2020

Hi, some more points from Luxoft side:

I don't expect it to be mention in proposal, but I would like to point that would be nice to implement it within another accepted proposal https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0126-atf-additional-transports.md. It contains a lot of requirements related to transport switching and to prerequisites of certain transport. Probably would be nice to make a revision to 0126-atf-additional-transports.md for full coverage of SDL 0245
We suggest changes to new RPCs:
- GetWiFiNetworkInfo: wifiState parameter should be mandatory.
- JoinWiFiNetwork: remove wifiState and make SSID and securityType mandatory.
- OnWiFiAPTransportStatus: make wifiState mandatory.
The WiFi connection can be automatically established only when Driver Distraction is OFF..
We need it only if phone is trying to connect to TCP_WIFI_STA_MODE and this one is specific to IPhone. But if we use mobile device as AP, we can do it silently I would propose to allow wifi connection if we can do it silently.
I feel app consent on launch as significant UX degradation. After app launch we should setup wifi connection and start service. It may take several seconds in real world.

If it is possible I would like to reduce consent impact to UI :
- Put in proposal that consent will be stored across connections and ignition cycles. May it should be even SDL responsibility.
- Send OnSystemRequest (WIFI_CONNECTION_RE) right after RAI, if consent is already available.
- Make consent not for app, but for device. So if one app from certain already did a consent, treat all other apps as already consented.

LuxoftAKutsan on 28 Jan 2020

Hi @ashwink11 please find responses from the PM below, thank you!

2/13. We do not agree with using the StartServiceAck at all. The flow described in the proposal does not allow the mobile device to communicate its own access point capabilities to the module, so there is no true access point negotiation that occurs through the StartServiceAck approach. If the RegisterAppInterface approach is used, the mobile device can use the RAI request to communicate what its own capabilities are. Then, Core will appropriately be able to decide who should be the access point based on its own capabilities with the mobile device.

Disagree with a: Adding a string to the protocol message will cause a version change to the protocol. Adding a new string has more of an impact than you are proposing.
Disagree with b: Crowding the start service ack is no different than the response RAI response. Also this flow does not allow for mobile to communicate its capabilities in the request.
Disagree with c: We do not agree that we should tie this feature to the secondary transports. There is simply no benefit to tie the two together, while we can protect for the future with minimal alterations.
Disagree with d: Adding new parameters to the .ini file requires minimal changes and we do not believe that avoiding those additions is justification for a suboptimal solution.

4/5. The desire for the developer to turn this feature on and off is understood, however, that is not what is being asked. Not all devices, OS versions, and data plans are capable of supporting this feature. The question is: how will the mobile library answer those questions and fill the data into those DeviceInfo fields declaring that the device supports this feature?

6. As stated previously, the vote happened to accept the ability to dynamically switch on the IVI system. We can raise this as a point that you do not agree with currently and would like to get a new vote on. So the best course of action will be to ask for yet another vote specifically:

Should the ability for an IVI system to support both AP and station mode be included in the feature? This means that the IVI system can be an AP itself or join the mobile devices AP which is determined at runtime. The IVI would use information and flows previously supplied to determine which mode it should operate in based on the first RAI received from the mobile applications. IVI systems are not required to support this operation and could still select to only support one mode. Otherwise, the IVI system will state in the INI file which mode it will always operate in, AP or station, but never both.

9. This is understood, but is not what is being asked. Earlier you stated, "The pop up is shown immediately after the user attempts to launch an App." which means that the "Connect WiFi to use this App" etc. popups would appear immediately, before the app has even had a chance to connect. This flow would be confusing to the user. That was why you agreed earlier to change the string to "Waiting for Wi-Fi" but that doesn't solve the problem of errors occurring or the app failing to connect. Based on your earlier agreed change, which is better for when the user clicks on the app, it no longer solves the problem of telling the user of a failure and what their action should be.

14. Regarding these points in the mobile api changes:

(2.) If the IVI is a WiFi access point, and the proxy did not receive WiFi credentials using GetWiFiNetworkInfo due to some error, the proxy should request credentials again using GetWiFiNetworkInfo only after receiving Transport Event Update protocol message with a valid IP address.
(3.) If the IVI is the WiFi access point, the proxy will receive Transport Event Update with an empty IP address when TCP transport is unavailable. The proxy will not try connecting WiFi if Transport Event Update with an empty IP address is received.

In the event of the mobile as the access point, shouldn't Core have similar requirements for retrying the connection?

15.

(1.) Using OnSystemRequest in the flow is unnecessary. It is creating an overly complicated flow. By using the flow outlined in this comment, only using JoinWifiNetwork requires one less step in the flow you are proposing.
(2.) OnSystemRequest is meant to signal mobile to perform an action and the send a SystemRequest to Core. Adding other RPC actions to this flow is outside the normal behavior for this RPC.
(3.) Using OnSystemRequest creates an asymmetric flow for when mobile is the access point. I don't think it's described in the proposal but are you suggesting that mobile sends an OnSystemRequest to Core to trigger the IVI to connect to the mobile access point? (The RPC in that direction does not exist fyi)
(4.) Using the JoinWifiNetwork flow, there is a clear success or failure communication flow independent on if the mobile or IVI is the access point.

16. I think I am looking for requirements similar to this:

If mobile is the access point and WiFi becomes available after app activation, mobile will send a JoinWifiNetwork to Core.
If IVI is the access point and WiFi becomes available after app activation, Core will send a JoinWifiNetwork request to mobile.

18. It has still not been addressed as to what will happen in the case when a second app is launched on the IVI that uses WiFi, but the first app that uses TCP is simply put into background. Based on the code you supplied, this will cause a WiFi network disconnection, closing the first apps TCP connection. This is not an acceptable flow. Please address this concern.

20. The current flow would be to try to connect to the TCP transport regardless of WiFi state. If that connection fails, the subsequent managers would fail to start and the developer would be notified. With this proposal I imagine if the information was available that a WiFi network could and should be joined/created, it would do so at this point before attempting the TCP connection. I would look to the author to define this exact flow as it is their proposal. Also, why would the HMI level be put back into NONE if the WiFi connection fails? I don't see that requirement anywhere, can you please provide more information?

22. As already stated, since this is an alternative I am not going to keep pushing this specific point. No further discussion is necessary.

23. It's JavaScript Suite. Also based on the author's modification on the originally accepted revisions, the Protocol platform would need to be added if accepted.

24. Based on your comment, this is an untestable feature for the iOS library, and untestable features should not be implemented into the iOS library as we'd just be guessing about what works at that point. Do you have a suggestion for how this should be tested?

I've updated the table to reflect the current state of comments, and combined some of the issue numbers based on our discussion. I've also added the new comments from the Luxoft team to this table.

theresalech on 28 Jan 2020

During the 2020-01-28 Steering Committee Meeting, the author requested clarification of Item Number 6 within the comments. The Project Maintainer provided the following background: when the Steering Committee originally voted to return this proposal for revisions (vote/rationale here), the feature was included in the IVI system as being able to handle both station mode and access point mode, and switch between the two. It wasn't required that the IVI system support both, but the SDL feature itself had to include it. Ford then asked to bring the proposal back into review without making the revisions (decision here), and within the items requiring Steering Committee vote (found here and in following comments), it was not specified that this switching be removed.

The ask from the Ford team in the comments was for Steering Committee members to vote again on if the IVI system should support both station mode and access point mode, and be able to dynamically switch between the two. The PM noted that within the SDL implementation of this feature, dynamically switching doesn't add much complexity, and cited their proposed implementation here. The author noted that some cases were not covered in this solution, and believed dynamically switching would add complexity to the feature.

Ultimately, it was requested by the Ford team to defer this proposal in favor of a separate workshop to work through all open items related to this proposal. The Steering Committee agreed to defer, and bring this proposal back into review after a workshop has taken place.

theresalech on 29 Jan 2020

Action Items from 2020-02-13 Workshop (to be provided as comments on this review issue when ready):

Ford to check with Android app partners to determine if they will use the feature if they are required to ask users for special permissions.
Ford to look into more information on testing pre-production without entitlements, and check with Apple regarding options for 3rd party apps implementing this feature. Based on these findings, check with iOS app partners to determine if they will use the feature if they're required to go through this process with Apple.
Livio to investigate options for testing on iOS without entitlement – creating separate development provisioning profile in debug.
Livio to update their proposed flow based on meeting discussion.

theresalech on 17 Feb 2020

As the workshop to discuss open items has taken place, and action items (see this comment) have been determined, the Steering Committee voted to bring this proposal back into review. The Ford and Livio teams will comment on this review issue with their workshop action items to further the discussion and assist the Steering Committee in informatively voting on the proposal.

theresalech on 19 Feb 2020

Based on the workshop we held, this was the base flow we agreed upon at that time as best as I could capture it. If I have incorrectly stated something please let me know, or if there are additional concerns/comments please feel free to add them. Once agreed upon in principal the action item would be to update the proposal with this version of the solution.

Potential Solution

Enable both Head Unit and Mobile devices to be Access Points

At a high level the flow is as follows:

HMI sends core an OnSystemCapabilities notification that includes the NetworkingCapabilities of the head unit
App sends RegisterAppInterface with new NetworkingCapabilities param as part of the DeviceInfo struct.
~Head unit~ Core sends RegisterAppInterface response
If app has permission to use feature, head unit uses info supplied in NetworkingCapabilities and its INI config file to determine best network setup.
Once the IVI system is ready to determine who should host the network and that the app has the correct permissions, it will send an OnSystemCapabilityUpdated with the determined network setup and actions.
The network is set up and joined.
1. If head unit should be network host:
  1. Core requests HMI sets up a WiFi network as an OnSystemCapabilities notification that includes NetworkingCapabilities and VEHICLE as the preferredNetworkHost (This could be a new request/response or notification not yet determined; opened to suggestions)
  2. HMI sets up network, sends JoinNetwork request with network info
  3. Once the request is received by Core, it will pass the JoinNetwork request that contains the information to join the network.
  4. When the app receives the JoinNetwork request, it will attempt to join the network. It will send the success or failure information in the response.
    1. If the OEM app is running is on iOS device, it may be required to put the app into the foreground to join the network programmatically. This will require HMI flows to be created to prompt the user to do so.
2. If the mobile device is selected to be the network host:
  1. The selected app will receive the OnSystemCapabilityUpdated response with the info that it is to host the network.
  2. App sets up "hot spot" WiFi network.
  3. Once network is up and running, app sends JoinNetwork request that contains the information to join the network to the head unit.
  4. When the head unit receives the JoinNetwork request, it will attempt to join the network, passing the request to the HMI .It will send the success or failure information in the response.
Core then sends the TransportEventUpdate protocol message with IP and port to connect the TCP transport to all appropriate apps. Flow is then as defined in previous secondary transport proposal.

Requirements

How are multiple apps handled when they all support this feature?
- The first RegisterAppInterface request Core receives that contains NetworkingCapabilities and is allowed to use the feature via policies will be used to determine the networking setup for that session or until all apps and transports have disconnected.
- Investigation is needed for iOS on this point. Running the iOS connect to wifi code should produce a notification that the user can interact with to connect to the wifi network. However, it needs to be shown that this feature will work with Do Not Disturb While Driving.
What happens when an additional RegisterAppInterface request is received by Core that contains NetworkingAbilities and has the necessary functional groups but the feature is already initialized?
- Core should not send the any OnSystemCapability notifications with the NetworkingCapabilities
- Core should reject any JoinNetwork request sent from that app with a result code of IGNORED
What should Core do if the mobile sends NetworkingCapabilities with their RegisterAppInterface but is not allowed to use the feature in policies?
- Core should not send the any OnSystemCapability notifications with the NetworkingCapability
- Core should reject any JoinNetwork request sent from that app with a result code of DISALLOWED
When does the secondary transport info get sent?
- The RPC StartServiceACK will still contain supported secondary transports including TCP
- Once the devices are connected to the agreed upon network, Core will send a TransportEventUpdated with the IVI’s IP and port
Should the entire creation and joining of a network be set up before allowing apps to enter HMI_FULL?
- Yes. In order to reduce loading time of apps using wifi as a secondary transport, having the auto join network feature complete before app moves into HMI_FULL state will be required.
Does the app need to subscribe for the NetworkingCapabilities updates from the head unit?
- If an app sent its NetworkingCapabilities in the RegisterAppInterface request and the app had the proper functional group associated with it in the policy table the app would be auto subscribed to the NetworkingCapabilities updates from the head unit
- Core should reject any GetSystemCapability request sent from any other app with a result code of DISALLOWED if functional group is not granted and IN_USE if the feature has already been set up.

RPC Flow

RPC Spec Changes

First, we expand the information provided in the RegisterAppInterface request through the DeviceInfo struct:

 <struct name="DeviceInfo" since="3.0">
 ...

    <param name="networkingCapabilities" type="NetworkingCapabilities" mandatory="false" since="X.X">
            <description>Device's available configurations around networking</description>
    </param>
 </struct>

These capabilities are related to what the phone can do, and what some of the networking preferences should be. This is further explained through the new struct NetworkingCapabilities and supporting Enums:

<struct name="NetworkingCapabilities" since="x.x">
    <description>Describes some of the sending device's available configurations around WiFi networking. This includes the ability to automatically join a network or host one itself.</description>

    <param name="autoJoinWiFiSupported" type="Boolean" mandatory="false">
        <description> </description>
    </param>

    <param name="canHostWiFiNetwork" type="Boolean" mandatory="false">
        <description> </description>
    </param>    

    <param name="dataFallbackSupported" type="Boolean" mandatory="false">
        <description> This describes the device's ability to support joining multiple networks and using one for internet connectivity if not available on a different, connected network.</description>
    </param>     

    <param name="accessPointSupportsInternetAccess" type="Boolean" mandatory="false">
        <description> True if the access point created by this device will support internet access to connected clients.</description>
    </param>     

    <param name="preferredNetworkHost" type="Device" mandatory="false">
        <description> This describes the preference of what device to use for the network host. This could mean the user prefers to use the data of either mobile or the vehicle when one might have unlimited data but a cap on another. When sent from mobile this will simply be a suggestion. When sent from the head unit, the mobile device should take this as determined host.</description>
    </param> 

    <param name="allowAccessPointToBeShared" type="Boolean" mandatory="false">
        <description> True if it is acceptable to share this network's SSID and password with other nearby devices. This is helpful if two mobile devices connected to a head unit, and one of them is selected as the network host.</description>
    </param>    

    <param name="wifiFrequencyBandsSupported" type="" array="true" minSize="1" maxSize="100" mandatory="false">
        <description> An array of frequencies supported by the device. Values should be in units of GHz for example 2.4GHz, 5.0GHz, etc </description>
    </param> 
    <param name="wifiSpecsSupported" type="String" array="true" minSize="1" maxSize="100" mandatory="false">
         <description> An array of WiFi Specifications, aka "Names", supported by the device. Currently expected values should be from the following: 802.11b = 1, 802.11a = 2, 802.11g = 3, 802.11n = 4, 802.11ac = 5, 802.11ax = 6.  </description>
    </param> 

</struct>

<enum name="FrequencyBand" since="x.x">
    <element name="FREQUENCY_BAND_2_4_GHZ"/>
    <element name="FREQUENCY_BAND_5_0_GHZ"/>
    <element name="FREQUENCY_BAND_6_0_GHZ"/>
</enum>

<enum name="Device" since="x.x">
    <element name="MOBILE"/>
    <element name="VEHICLE"/>
</enum>

Networking Capabilities

preferredNetworkHost

When sent from mobile in the DeviceInfo struct this should be referred to as a suggestions to the head unit to help determine who should be the network host. The most common use case for this to be set will be when a user has provided a selection of data usage preference. Some users will have unlimited data on their mobile device, but not their vehicle. Therefore it makes sense that they would want to use their mobile device if possible.

When this is sent from the Vehicle in an OnSystemCapabilityUpdated notification, it should be taken as the determined network host. The mobile device should honor this param for the feature and take action based upon its value.

allowAccessPointToBeShared

Because head units can allow multiple devices to use SDL at a time it is reasonable to expect that each device will still desire to be on the same network. Because of this and the fact one of the mobile devices could be the network host, if the app allows the WiFi info to be shared they should set this to true. The head unit will then share this info by sending a JoinNetwork request with the shared info.

Next we add a param in the RegisterAppInterface response:

<enum name="SystemCapabilityType" since="4.5">
        <description>Enumerations of all available system capability types</description>
            ...
        <element name="NETWORKING" since="X.X"/>
    </enum>

    <struct name="SystemCapability" since="4.5">

        ...

        <param name="networkingCapabilities" type="NetworkingCapabilities" mandatory="false" since="X.X">
            <description>Describes capabilities for networking </description>
        </param>

    </struct>

Join Network RPC

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="request" since="X.X">
    <description>A request for the receiver to join the specified network.</description>
    <param name="wifiState" type="WiFiStateInfo" mandatory="false">
        <description>wifi state info</description>
    </param>
    <param name="ssid" type="String" minlength="1" maxlength="32" mandatory="false">
        <description>name of the WiFi ssid</description>
    </param>
    <param name="password" type="String" minlength="1" maxlength="100" mandatory="false">
        <description>password to use to connect AP</description>
    </param>
    <param name="securityType" type="WiFiSecurityType" mandatory="false">
        <description>security type of WiFi AP</description>
    </param>   
</function>

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="response" since="X.X">
    <description>A response and description of requested action.</description>
  <param name="success" type="Boolean" platform="documentation" mandatory="true">
    <description> true, if successful; false, if failed </description>
  </param>

  <param name="resultCode" type="Result" platform="documentation" mandatory="true">
    <description>See Result</description>
    <element name="SUCCESS"/>
    <element name="UNSUPPORTED_RESOURCE">
    <element name="DISALLOWED"/>
    <element name="REJECTED">
    <element name="TOO_MANY_PENDING_REQUESTS"/>
    <element name="APPLICATION_NOT_REGISTERED"/>
    <element name="GENERIC_ERROR"/>
    <element name="USER_DISALLOWED"/>
    <element name="DATA_NOT_AVAILABLE"/>
  </param>

  <param name="info" type="String" maxlength="1000" mandatory="false" platform="documentation">
    <description>Provides additional human readable info regarding the result.</description>
  </param>   
</function>

<enum name="WiFiSecurityType">
  <description>enum to define WiFi security types used for WiFi connection.</description>
  <element name="NONE"/>
  <element name="WEP"/>
  <element name="WPA"/>
  <element name="WPA2"/>
  <element name="WPA3"/>
</enum>

<enum name="WiFiStateInfo">
  <description>enum to define WiFi state.</description>
  <element name="WIFI_STATE_DISABLED"/>
  <element name="WIFI_STATE_ENABLED"/>
</enum>

Determining which device should host the network

Once the head unit receives the RegisterAppInterface and the NetworkingCapabilities it must decide who should host. Each bullet point assumes that the network configurations can be supported by both devices (frequencies, data fallback, etc). These bullet points are just a suggestion, an OEM can determine the situation themselves.

MOBILE (assuming canHostWiFiNetwork in NetworkingAbilities is set to true from mobile)
- Core set MOBILE as the only device in the INI file
- If Core set BOTH and the mobile device does NOT support dataFallbackSupported
- If Core set BOTH and the mobile device set dataUsagePreference to MOBILE value
VEHICLE (assuming canJoinNetwork in NetworkingAbilities is set to true from mobile)
- Core set VEHICLE as the only device in the INI file
- If Core set BOTH and the mobile device DOES support dataFallbackSupported
- If Core set BOTH and the mobile device sets dataUsagePreference as VEHICLE
- If any other settings mismatch, this will be the default

Additional Information

Can either be a hotspot or a common, known WiFi connection
Android
- startLocalOnlyHotspot() - “The network created by this method will not have Internet access.”
- When creating a hot spot programmatically, the result will not allow clients to share the internet connection of the mobile device
- User could create an access point with internet access and the app could ask IVI to join
- User could set preferred WiFi network
iOS
- Unable to create an access point programmatically
- User could create an access point and the app could ask IVI to join
- User could set preferred WiFi network

Potential Downsides

Android Permission Issue

android.permission.WRITE_SETTINGS required for Android SDK 29+
This permission is a “system” permission. This causes an error message in the manifest.xml editor to appear
User must specifically grant this permission. This is not the same as a location permission request, it is a distinct permission with its own settings page.
Will require a dialog/pop up explaining why the user must grant this permission and then forward the user to the settings page where they can grant it.
Because this feature can be used by any app (not just a single OEM app), this will require a pop up and user redirect for all apps that are going to use the feature.

iOS Entitlement Issues

The feature could be difficult to test on iOS. If it's not easily tested, regression issues could easily surface.
Each app will need to apply to Apple for the entitlement
Joining the network requires the user to interact with the device each time
- “[app] Wants to Join Wi-Fi Network”

OEM Apps Only vs All Apps

Because of the extra requirements for app developers to implement and processes to go through for this feature to work, it is plausible that no 3rd party apps will implement this feature. This would then incur a large sum of technical debt to the project without being warranted. This feature will likely be required to be implemented into OEM apps as it stands if we can't guarantee a 3rd party app will implement this feature.

Networking Information Not Encrypted

The proposal leaves open the possibility that networking information is sent unencrypted between a head unit and a mobile device via SDL. Any OEM implementing this feature should be aware of the risks that this might cause to their users and carefully decide if they wish to allow the feature to operate unencrypted. This proposal does not prevent an OEM from requiring encryption to use this feature though.

Impact to Existing Code

Each app platform SDK's System Capability Manager will need to be updated to handle the new NetworkingCapabilities
A new NetworkManager will likely need to be created to handle most of the basic functions of this feature. The manager itself should be mostly private and therefore should be able to be an implementation detail. It should be required the app developer has a way to enable/disable this feature for their app.
The policy server will have to be updated with the new RPCs and handle a new functional group for this feature, something like NetworkingGroup.
The developer portal will need to be updated with an option for app devs to apply for this permission.
Core and HMI will require changes that let them pick the best candidate to handle this feature.

joeygrover on 19 Feb 2020

@joeygrover After checking I have found out that diagram above specifies OnServiceUpdate usage incorrectly. With its current structure SDL core can not notify the HMI that some service (e.g. 0x07 ) was started encrypted.
Now there is no parameter which can help to distinguish if the service encrypted . Please see:

<interface name="BasicCommunication" version="2.1.0" date="2019-03-18">
<function name="OnServiceUpdate" messagetype="notification">
  <description>
    Must be sent by SDL to HMI when there is an update on status of certain services.
    Services supported with current version: Video
  </description>
  <param name="serviceType" type="Common.ServiceType" mandatory="true">
    <description>Specifies the service which has been updated.</description>
  </param>
  <param name="serviceEvent" type="Common.ServiceEvent" mandatory="false">
    <description>Specifies service update event.</description>
  </param>
  <param name="reason" type="Common.ServiceStatusUpdateReason" mandatory="false">
    <description>
      The reason for a service event. Certain events may not have a reason, such as when a service is ACCEPTED (which is the normal expected behavior).
    </description>
  </param>
   <param name="appID" type="Integer" mandatory="false">
       <description>ID of the application which triggered the update.</description>
   </param>
</function>

If we want to use this notification in the proposed way - we have to extend it somehow.
May be extend parameter ServiceStatusUpdateReason?
2) There is no RegisterAppInterface RPC in HMI API. When SDL receives RegisterAppInterface request from mobile app, SDL core sends notification to the HMI with all related information and there is no response from the HMI is expected.
Then SDL replies with the RegisterAppInterface response to mobile app.
Here is how the notification looks:

    </function>
    <function name="OnAppRegistered" messagetype="notification">
      <description>Issued by SDL to notify HMI about new application registered.</description>
      <param name="application" type="Common.HMIApplication" mandatory="true">
        <description>The information about application registered. See HMIApplication. </description>
      </param>
      <param name="ttsName" type="Common.TTSChunk" minsize="1" maxsize="100" array="true" mandatory="false" >
        <description>
          TTS string for VR recognition of the mobile application name, e.g. "Ford Drive Green".
          Meant to overcome any failing on speech engine in properly pronouncing / understanding app name.
          May not be empty.
          May not start with a new line character.
          Not unique value
        </description>
      </param>
      <param name="vrSynonyms" type="String" maxlength="40" minsize="1" maxsize="100" array="true" mandatory="false">
        <description>
          Defines an additional voice recognition command.
          Must not interfere with any name of previously registered applications from the same device.
        </description>
      </param>
      <param name="resumeVrGrammars" type="Boolean" mandatory="false">
        <description>The flag if VR grammars resume is required</description>
      </param>
      <param name="priority" type="Common.AppPriority" mandatory="false">
        <description>Send to HMI so that it can coordinate order of requests/notifications correspondingly.</description>
      </param>
    </function>

AByzhynar on 19 Feb 2020

3.

If the OEM app is running is on iOS device, it may be required to put the app into the foreground to join the network programmatically. This will require HMI flows to be created to prompt the user to do so.

The flow you shared does not mention how an app would be put in foreground. Could you please clarify on this requirement?
I observed that iOS app does not need to be in foreground when connecting to Wi-Fi. Did you have different observations? Can you explain why iOS app needs to be in foreground to join Wi-Fi network programmatically?
Should this requirement be applicable for Android 10 as well?

4.
Can you please clarify the flow when the mobile device and IVI are connected to Wi-Fi before any SDL app registration? For example: User first connects Wi-Fi manually and then connects on primary transport(Bluetooth).
If IVI and mobile device is already in the same Wi-Fi network, do they need to send JoinNetwork RPC?

5.
Regarding preferredNetworkHost

The most common use case for this to be set will be when a user has provided a selection of data usage preference. Some users will have unlimited data on their mobile device, but not their vehicle.

Can you please clarify how an SDL app determines that user has unlimited data on their mobile device but not on vehicle? Are you suggesting any user settings? If yes, who should implement these settings, proxy or app?

allowAccessPointToBeShared

This seems to me as privacy issue. What if user does not want to share access point with other devices?
Will mobile proxy ask for user consent on mobile device if this option is enabled by an SDL app?

> User could create an access point with internet access and the app could ask IVI to join

Does this means users creates Wi-Fi hostpot using device settings menu? If yes, how will an app ask IVI to join to this network?

> startLocalOnlyHotspot() - “The network created by this method will not have Internet access.”

If IVI is Wi-Fi access point and does not provide the internet, the mobile device OS will use a mobile network internet when the IVI access point does not have data connectivity. And, as mentioned in the quoted text, the internet will not be available if the mobile device is creating access point programmatically.

Since, in both cases, the mobile OS takes care of switching to the mobile internet connection, can you please clarify how dataFallbackSupported parameter will be used?

9.

User could create an access point and the app could ask IVI to join

Does this mean users create Wi-Fi hotspot using the device settings menu? If yes, how will an app ask IVI to join? Can you please provide a flow?
I guess iOS apps do not have access to the Wi-Fi credentials of a hotspot created by the user in device settings.

ashwink11 on 20 Feb 2020

1. Ok, it's likely not needed. I think moving the OnSystemCapability notification after the app starts an encrypted RPC service will work just fine then. Core will simply send the JoinNetwork request after that.
2. There is no RAI going to the HMI, the flowchart shows OnAppRegistered. Please clarify your issue here.
3. This was information I had from the workshop. If it is incorrect we can remove. iAP already has a method to request the app move to the foreground and the OnHMIStatus notification sent from mobile lets core and hmi know this. This is not new or part of this proposal. Android does not have any requirements for UI to be brought to foreground, the same service standards apply.
4. As shown in the flowchart if the feature is has already been used the OnPermissionChanged notification will not be sent and therefore no more of this feature will take place. If this is not a satisfactory answer and because this issue existed the same as stated in the original proposal, I will await your suggestion for your proposal.
5.This is not in the library to determine. This can be an added preference to an OEM app that will enrich the feature with little effort.
6. That is the point of the flag. Again this is an issue present in the original proposal (multiple devices using this feature), as you are the author I will await your suggestion.
7. Yes. An OEM could provide such feature and the param adds little effort.
8. You misunderstood. The hotspot does not provide internet access to clients (the vehicle will not be allowed to use internet through the device). The phone still has internet access.
9. See 7.

joeygrover on 20 Feb 2020

@joeygrover regarding 2 - the flowchart is correct. But in the proposed solution:
https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-588434670

3rd step:

3. Head unit sends RegisterAppInterface response

It is likely should be removed as the head unit is not able to send it.

AByzhynar on 21 Feb 2020

@AByzhynar I don't understand your comment. Core will send an RAI response and the flowchart is the exact same.

joeygrover on 21 Feb 2020

@joeygrover Yes. You are right. I thought the HMI (instead of the entire Head Unit) would send RAI response.
I am sorry for the confusion.

AByzhynar on 24 Feb 2020

@AByzhynar I see, I will clarify. I shouldn't have used "head unit" in general terms and been specific between Core or HMI.

joeygrover on 24 Feb 2020

1. So, should SDL send OnSystemCapabilityUpdated to HMI when encrypted RPC service established? Should SDL mirror network capabilities from RAI there?

10. Is it correct that the app should not be Activated if there is no Wifi connection? Is it SDL or HMI responsibility? Also, I can see at least one failed sequence because we can do PTU only via app in FULL.

One NAVI app connected to SDL, Policies is not updated.
OnSystemCapabilities not sent because of missed policies, JoinNetwork also disallowed.
The app is not able to Activate because WiFi connection not established.

11. It is not clear if SDL decides AP placement based on HU OnSystemCapabilities received before RAI, and device Network capabilities from RAI? Or SDL should wait for OnSystemCapabilitiesUpdated from HMI after OnAppRegistered?

These bullet points are just a suggestion, an OEM can determine the situation themselves.

If sdl_core will implement suggested in proposal rules, how OEM can change it?

12. Should SDL restrict _HMI -> SDL -> Mobile_: JoinNetwork request, if decided that mobile should be an AP.

13. Still not clear behavior with multiple devices. If HU is connected to device1 AP (allowAccessPointToBeShared = false), the app on the second device will not be able to establish a WiFi connection at all? How can the user activate the second app?

14. How should SDL decide if different apps are on the save device? Based on Transport level information, or based on DeviceInfo section from RAI?

15. Not clear behavior with several apps on one device. If the first connected app is allowed for Wifi connection. But does not perform it. Should SDL send OnSystemCapabilities to the second app after some timeout? If the first app is unregistered, and there is still no WifiConnection, should SDL send OnSystemCapabilities to the second app?

16. The app will be automatically subscribed to OnSystemCapabilityUpdated in case if it has correct permissions. Can the app unsubscribe from this notification?

17. Should SDL allow GetSystemCapabilities(NETWORKING) for apps?

18. Should HU disconnect from mobile AP if no apps connected from this device?

19. If 2 apps from different devices with wifi permissions registered, and the first one successfully established Wifi connection. Then first one unregisters, should SDL send OnSystemCapabilityUpdated to the second app on the second device?

20. HU allows Wifi connection if no explicit JoinNetwork request was sent? It affects the disconnect\connect Wifi use case.

21. If the user turns off\turn on AP, while service is established, should mobile app request JoinNetwork one more time without waiting for OnSystemCapabilitiesUpdated?

22. If multiple registered apps allowed for Wifi connection after PTU, which one should SDL choose? Should it remember the registration sequence?

23. ini file format is not clear, what keys and values should it contains?

LuxoftAKutsan on 24 Feb 2020

Yes I believe that is correct. Notification should be sent to the hmi if the app sent the networkingCapabilities in the RAI, has the necessary permissions, and fits all the cases where the mobile device will be the negotiated access point.

10.

The app can be activated without a wifi connection. I believe that is no different than the current secondary transport implementation? The wifi sharing and connection flow should happen after activation in case of policy table udpates for external policy build. Regular policies should not have this issue.

The OnSystemCapabilities would be sent after the PTU if the new update includes JoinNetwork permissions for the app.

Core should use the most recent capabilities received from the HMI along with the app's network capabilities sent at registration.
Ok that is a good idea.
They will not be able to establish a wifi connection.
Either would work fine but i believe the device handle from the transport level is the main method in core for detecting the device.
I like to avoid arbitrary timeouts for feature implementations.

If the first app is unregistered, and there is still no WifiConnection, should SDL send OnSystemCapabilities to the second app?

This should be enough since the app would be unregistered if it is not able to use its secondary transport. I dont think a timer is required.

Can an app unsubscribe from display capabilities? I don't think it can. Maybe the same behavior should apply to the networking capabilities.
The proposed implementation doesn't mention GetSystemCapabilities but i guess that RPC is implied because all other capability types include that rpc. I think GetSystemCapabilities(NETWORKING) should only be allowed for apps that communicated networking capabilities in the RAI and have join network permissions. Same flow as calculating the OnSystemCapabilities permissions.
I think that is up to the HMI implementation.
Yes I think it should be sent but most cases nothing should happen because there is already an established access point and wifi connection.
Yes it should allow the connection. In the case of auto reconnection there does not need to be a join network.
No not needed unless the wifi credentials changed or auto reconnect is false.
Yes i think core should cache the first networking capabilities received from mobile.
Open to suggestions, but here is mine:

[AccessPoint]
;NetworkHost = MOBILE, VEHICLE, ALL, or NONE
NetworkHost = ALL

JackLivio on 24 Feb 2020

OnSystemCapability does not give a clear indication to HMI that service is encrypted and could be used for both unprotected and protected services for different capabilities. As shown in the proposed flow diagram, we suggest using OnServiceUpdate notification to update HMI about encrypted service. We can add a new param in OnServiceUpdate that represents service encryption status.
Yes, I remember we discussed in Workshop, I also mentioned that APIs worked with the app in the background when background mode "External accessory" is enabled. Since the proposed changes mentioned that App should be in the foreground, I asked you, if you guys observed different behavior. If not, then we can remove it.

Another point is regarding Android 10 behavior for Wi-Fi transport APIs, I observed that for Android 10 the App needs to be in the foreground. How do we bring Android 10 apps in the foreground?

In the updated flow I showed in Workshop, it shows that the proxy should check for reachability (whether TCP connection can be established) after receiving system requests. In this flow since HMI is sending an RPC, we do not have OnSystemRequest notification. If the proxy knows about the connection status, beforehand, it would be great.
Since this updated flow is your suggestion, I thought you might have some inputs, anyways, I have the following suggestion, let me know your thoughts.

One option is to allow apps to register on secondary transport as soon as the TransportEventUpdate control frame is received. If IVI is AP and HMI detects that App is already registered on secondary transport, it will not send JoinNetwork RPC. Similarly, if the mobile device is AP and it detects that App is already registered on secondary transport, it will not send JoinNetwork RPC.

Since this updated flow is your suggestion, I thought you might have some inputs. So, I would suggest adding a configuration in the SDL INI file, whether to allow such behavior or not. This flag "allowAccessPointToBeShared" behavior should be controlled by OEM.

[AccessPoint]
;NetworkHost = MOBILE, VEHICLE, ALL, or NONE
NetworkHost = ALL
;AllowAccessPointToBeShared = TRUE or FALSE
AllowAccessPointToBeShared = FALSE

7.& 9.

I was asking you to clarify the quoted statement.

User could create an access point with internet access and the app could ask IVI to join

This statement is mentioned for both Android and iOS devices. From your response, it is connected to some parameters. I am not sure, to which parameter it is connected too. Also, how would proxy know that user-created Wi-Fi hotspot using device settings?
Can you please explain?

Please confirm the below behavior.

In all these scenarios, mobile OS is managing internet connectivity. Can you please clarify how the dataFallbackSupported parameter value is determined by mobile proxy and how it will be used by Core?

10.

The app can be activated without a wifi connection.

Below statement from this comment.

Should the entire creation and joining of a network be set up before allowing apps to enter HMI_FULL?
Yes. In order to reduce loading time of apps using wifi as a secondary transport, having the auto join network feature complete before app moves into HMI_FULL state will be required.

These two statements seems to be contradicting. Can you clarify this requirement and statement made?

15.

This should be enough since the app would be unregistered if it is not able to use its secondary transport.

I don't remember any requirement that we discussed anywhere stating that App would be unregistered if secondary transport is not available. Can you please clarify on this?
Who is going to unregister app Core or proxy or HMI?

Edit: table in point 8

ashwink11 on 25 Feb 2020

> Core then sends the TransportEventUpdate protocol message with IP and port to connect the TCP transport to all appropriate apps.

Is this requirement only applies if the Mobile device is a Wi-Fi access point?
If IVI is a Wi-Fi access point, it should be allowed to send TransportEventUpdate even before join network RPC is sent.

ashwink11 on 25 Feb 2020

6. So HU may share credentials of another mobile only in case if AllowAccessPointToBeShared = TRUE in ini file and
allowAccessPointToBeShared = true in RAI (NetworkCapabilities)

10. Do we have any guidelins of HMI behavior when Navi\Projection app is activated, but apropriate service is not started?
Probably we shluld follow and extend https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0211-ServiceStatusUpdateToHMI.md

11. I mean, that final desigion is done on sdl_core side, based on:
mobile, hmi network capabilities and ini file content.
Also note, that HMI should make the same desigion to send JoinNetwork if target should be the AP.
Consider this 2 sequences :
SDL decide that device should be AP

SDL decide that vehicle should be AP

13. Shoudl SDLC give any guidelines for OEMs, how OEM should tel to the user that application required WifiConnection, but it cannot be done automagicaly.

14. Is it possible that 2 application from the same device will be connected by diferrent transports? BT and USB?
For sdl_core transport layer it will be 2 apps on different devices, and both will receive OnSystemCapabilities(NETWORK)

16. Ok. Thanks.

17. I would like to avoid spreading JoinNetwork RPC policy permissions to another RPC's like OnSystemCapabilityUpdated and GetSystemCapability
Would be nice to mention explicitly in policies permission for each RPC.
Another option is extending policies functionality to provide ability controll not only RPC's and param list, but also params content.
To DISALLOW OnSystemCapabilities(NETWORK) or GetSystemCapabilitisUpdate(NETWORK).
IMHO, this is not a big issue, if arbitary application will be able to get HU Wifi credentials by secured RPC service.

18. If app is unregistereed, SDL should know if Wifi is still connected to provide correct OnSystemCapabilitiesUpdated to next mobile.
HMI probably can send OnSystemCapabilitiesUpdated each time, when OnSystemCapabilities is actually updated (ex : Wifi connection established\broken)

19. So SDL should wait for OnSystemCapabilitiesUpdated from HMI, with information, that HMI is ready for new Wifi connection and then send it to Mobile?
Please see following sequence:
Multiple apps

22. So SDL should probably cache all NetworkCapabilities received from mobile, and registration sequence.
Because first application may be unregistered before PTU done

LuxoftAKutsan on 25 Feb 2020

The Steering Committee voted to defer this proposal, to allow the author and Luxoft team to discuss details and requirements offline, and report back to the Steering Committee their desired revisions. The Steering Committee will then be able to vote to return this proposal for revisions. It was noted that before the revised proposal is brought back into review, the other action items from the proposal workshop should be addressed. It was specifically discussed that understanding if 3rd party app developers will be using this feature will impact the proposed flow of the feature (not just who can use the feature), and should be reflected in the revised proposal.

theresalech on 26 Feb 2020

Unlocking the issue so the Ford/Luxoft teams can leave a comment with their desired revisions, and other action items from the proposal workshop.

theresalech on 26 Mar 2020

On the latest workshop, we agreed on the solution suggested by Livio : https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-588434670 .
Open issues were resolved internally and the final solution is ready https://github.com/smartdevicelink/sdl_evolution/pull/981

During work on solution were found even more open questions and created many workarounds to fix them.

Therefore Luxoft prepared another version of the proposal based on the latest workshop results, with a simplified approach: https://github.com/smartdevicelink/sdl_evolution/pull/980

But both solutions are ready and can be applied but Luxoft and Ford agreed that https://github.com/smartdevicelink/sdl_evolution/pull/980 (minimal approach) is preferred.

Drawbacks of https://github.com/smartdevicelink/sdl_evolution/pull/981 solution :

The solution is extremely complicated.
3 layer resolving (abilities - preference - ini file) for WiFi AP placement is not obvious.
SDL should decide on Wifi access point placement because SDL does not have access to wifi adapter. It would be better to follow the Information expert pattern and make the decision in the place where we have access to hardware.
Multiple device connection requires additional logic of postponing calculating NetworkSettings for each app\device
Many additional terms in the scope of SDL (feature enabled app, feature initialized app, etc ... )
Guides for HMI are very strict (for example HMI should send OnSystemCapabilitiesUpdated after connecting event if capabilities were not updated)
HMI miss information about the application that connects to the vehicle Wifi, such solution probably will be completely incompatible for example with Toyota existing solutions

Considering the following benefits we recommend accepting a simplified minimal approach solution:

Design is more straightforward.
The proposal is small and easy to understand.
Implementation considered to be small and testable
OEM probably can integrate it to existing solutions with minimal modifications of theirs HMI

LuxoftAKutsan on 31 Mar 2020

Hi @LuxoftAKutsan, thank you for your comment. In order for the Steering Committee to informatively vote on returning this proposal for revisions, we will need to identify what those revisions will contain. Therefore we will need the Ford/Luxoft teams to provide a summary of each solution (980 and 981) as well as a the revisions required to the proposal as it currently stands for each solution. The Steering Committee can then decide which solution/set of revisions is preferable and vote to return the proposal for revisions.

theresalech on 31 Mar 2020

Thanks @theresalech

Both solutions completely differ from existing proposal state and mostely based on soltion proposed by livio in https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-588434670 and workshop results

Summary for #981 :

The solution grows from workshop results with resolving all open questions for now.

Key points :

SDL decide where AP will be located based on: HU networking capabilities and preference, Mobile network capabilities and preference, ini file.
Single bi-directional JoinNetwork RPC.

Summary for #980 :

The minimal solution also based on Livio proposition https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-588434670, but with the rethinking of several concepts.

Key points:

SDL becomes a lightweight proxy for sharing SSID, no special logic on the SDL side.
Separate RPCs for sharing Mobile SSID with HU (JoinMobileNetwok) and sharing HU SSID with Mobile (JoinVehicleNetwork)

LuxoftAKutsan on 1 Apr 2020

Hi @LuxoftAKutsan, thank you for your quick response in providing these details! Given this new information, and to best follow the SDL Evolution Process for this unique situation, I think we should ask that the Steering Committee return this proposal for the following revisions:

Update proposal to reflect the solution in https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-588434670 as you mentioned.
Include a descriptive summary of the new "minimal solution" within the "Alternatives Considered" section of the proposal.

This way, the Steering Committee can review both options under the standard SDL Evolution Process.

theresalech on 1 Apr 2020

Minimal solution added to Alternative considered. You can see both solutions in PR https://github.com/smartdevicelink/sdl_evolution/pull/981

LuxoftAKutsan on 7 Apr 2020

👍1

As the Ford and Luxoft teams have identified their desired revisions to this proposal, the proposal is now back in review. The Steering Committee will review the desired revisions, and can move forward with voting on next steps (ideally to return the proposal for revisions) during our next meeting on 2020-04-14. The proposed vote for Steering Committee consideration can be found in this comment.

theresalech on 15 Apr 2020

The Steering Committee voted to return this proposal for the following revisions: update the proposal to reflect the solution in this comment, and include a new “minimal solution” in the “Alternatives Considered” section of the proposal.

theresalech on 22 Apr 2020

The author has revised the proposal to reflect the requested Steering Committee revisions, and the revised proposal is now in review until June 2, 2020. Exact changes made since the last version of this proposal was reviewed can be found in this merged PR: https://github.com/smartdevicelink/sdl_evolution/pull/981.

theresalech on 27 May 2020

From Luxoft side there are several concerns regarding the existing solution :

Complicated no obvious way to decide if mobile or Vehicle should be an AP. The decision is based on :
- INI file Configuration
- Current vehicle network capabilities
- Mobile network capabilities
  For OEM is hard to configure SDL in a manner that it wants for each particular case.
  SDL has no low-level access to the hardware and gets information about vehicle network capabilities via HMI_API.
  Race conditions are possible if several applications are registering one by one.
  From the Luxoft perspective would be good to keep SDL as a proxy with only one intention - sharing Wifi credentials.
  The solution that reflects this idea is in alternatives considered section : [Minimal approach solution])(https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md#minimal-approach-solution)
  Ford and Luxoft agree that this approach is desired.
Bidirectional usage of NetworkingCapabilitie with different intentions with a different meaning of parameters.
Consider preferedNetworkHost. The first time mobile send NetworkingCapabilities via RAI, and HMI via UI.GetCapabilities (btw it is also confusing) with initial network capabilities.
Then SDL sends NetworkingCapabilities to HMI/Mobile with to notify about AP placement, chosen frequency, security type, etc ...
And after JoinNetwork HMI should send NetworkingCapabilitie to SDL with updated values if another device will be connected.
In different cases some parameters are redundant and some of them have a little bit different meaning in certain use cases. NetworkingCapabilitie have at least 2 intentions: information about available networking capabilities and information about chosen network configuration
Bidirectional usage of JoinNetwork RPC. I feel bidirectional RPCs not enough explicit.
That is a minor concern, but I do not see any issue with creating separate RPC for JoinMobileNetwork and JoinVehicleNetwork
The solution that reflects this idea is in alternatives considered section : [Minimal approach solution])(https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md#minimal-approach-solution)
Ford and Luxoft agree that this approach is desired.
If the application allows sharing Wifi credentials for other mobile devices. Other mobile devices should know that they are connecting to an external Wifi hotspot but not Vehicle one.
Propose to add additional EXTERNAL networkHost.
In cases with multiple devices and applications that want to use the feature race conditions are possible, which makes implementation even more complicated and not obvious.

Considering complexity on this approach Luxoft and ford agreed that [Minimal approach solution])(https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md#minimal-approach-solution)
from alternatives, consider is preferred one.
The main intention of the Minimal solution is to keep SDL as a lightweight proxy for sharing networking capabilities and Wifi credentials.

LuxoftAKutsan on 28 May 2020

Hi @LuxoftAKutsan, the Project Maintainer has reviewed this revised proposal, and has the following feedback with regards to your comment as well as additional feedback regarding the "Minimal approach" described in the Alternatives considered section.

1.
We strongly disagree that there is "no obvious way" to determine if Mobile or Vehicle is AP. The proposal lays out the steps clearly in "Determining which device should host the network"

For OEM is hard to configure SDL in a manner that it wants for each particular case.
SDL has no low-level access to the hardware and gets information about vehicle network capabilities via HMI_API.

We disagree and see no differences between this proposal and the "minimal approach".

Race conditions are possible if several applications are registering one by one.
We disagree and see no differences between the original approach and the "minimal" approach.

The proposal states, "registration process is sequential and since it will cache registration order, there will not be race conditions during registration."

From the Luxoft perspective would be good to keep SDL as a proxy with only one intention - sharing Wifi credentials.

This doesn't make sense. In either approach SDL needs to handle connecting sending credentials or connecting to the mobile AP.

2.
We disagree and see the NetworkCapabilities struct as being sufficiently generic to allow for any AP. 'NetworkCapabilities' is only a struct, (read data structure). This means there is no specific intention around what that struct does because it is only a struct, not a function. This allows us to use this struct in different places. For example, we use it in the RAI from the mobile device because it fits our needs to supply the information to Core. The HMI uses this struct to send to Core as well, since again, the structure fits the need. Using the same struct between the two, Core can then compare them directly to create the desired outcome that will be sent to the application in the same structure. Creating unique structs for these cases would be the opposite of minimal.

3.

Bidirectional usage of JoinNetwork RPC.

We disagree. The JoinNetwork RPC is generic enough that it can be used in both situations. Where the network is located isn't necessary knowledge and is inferred from context. The RPC is telling the recipient to "join this network", it doesn't matter where that network is located.

4.
This doesn't seem objectionable to us.

5.

In cases with multiple devices and applications that want to use the feature race conditions are possible, which makes implementation even more complicated and not obvious.

Based on what information from the proposal? Can you be more explicit about where you see race conditions and how the "minimal" approach fixes that?

PM's feedback regarding the "Minimal approach"

6.
The "minimal" approach appears to have removed the dynamic role-switching "BOTH" mode that was explicitly voted upon by the Steering Committee and approved. The motivation of the "minimal" approach appears to be to have the Steering Committee re-visit an already voted and agreed upon feature component. See this comment. Is it your intention to have the Steering Committee re-visit this approved feature component?

7.

The proposed approach is designed to avoid bidirectional RPCs because it adds technical complexity that causes additional bugs.

We disagree that there is an issue with using bidirectional RPCs. See AppService related RPC's and OnSystemCapabilityUpdated notification. This comment should be removed from the proposal.

8.
The author claims that the main approach adds extra notifications but OnSystemCapabilityUpdated notification already exists in SDL Core today. ReadyForWifiConnection is presented as a new notification in the minimal approach but is not used at all in the flowchart. The minimal solution is adding the extra notification but then does not really describe its usage. It is then stated that ReadyForWifiConnection it should be removed in the Alternative Solutions section of the minimal approach. Can you please address this?

9.

This approach can be easily integrated into some already existing solution because there is no additional logic on SDL Core, and an OEM may just adopt an existing solution for using new APIs.

What does this mean? Is the author trying to state that this approach could simply be merged into an older version of IVI system that doesn't implement the newer version of Core? Because if so, that is not a possibility.

10.
It is not clear in the minimal approach when the HMI should send its first Join mobile/vehicle network request to Core. We believe the proposal should include some guidelines about certain types of triggers an HMI should use to send join network requests to Core.

11.

<param name="appID" type="Integer" mandatory="true">
      <description>Unique (during ignition cycle) ID of the application.</description>
    </param>

This is used in several locations in the minimal approach; where is this ID defined and why was it added?

12.
wifiSpecsSupported was removed in the minimal approach. Why was it removed and how do you handle telling a device that only supports, for example, WiFi spec g, that it cannot connect to a network that runs only on WiFi spec n?

13.
Why was Device renamed to NetworkHost? If we ever want to differentiate between the app and the device in the future, we will either have to redefine a new enum with the same values, or use NetworkHost as the type, which will be awkward.

14.

<function name="OnServiceUpdate" messagetype="notification">
  <param name="encrypted" type="true" mandatory="false">
</function>

This change mentioned in the minimal approach should be added to the main approach method. Missing the encrypted parameter was an oversight from the original revision.

15.
The minimal approach lists this as an Alternate Solution suggestion:

Use OnSystemRequest with subtype WIFI_READY_TO_CONNECT instead of ReadyForWifiConnection

But the minimal approach already is suggesting OnSystemRequest be used in its flowchart. What is the real intended behavior for the minimal approach regarding OnSystemRequest and ReadyForWifiConnection?

16.
In the main proposal

Application activation of feature enabled application will make this application the active for feature initialization.

If we can add the encrypted param suggested in Item 14 to the main proposal, we should be able to allow the JoinNetwork message to be sent after registration instead of app activation since a PTU won't be necessary for updating certificates if an encrypted RPC service was already started.

theresalech on 2 Jun 2020

Dear colleagues,
Upon investigation on mobile side both iOS and Android we came up with the following result:

Android:
On the latest versions (since 8.0 Oreo) due to api changes local hotspot will not have access to global network android
https://developer.android.com/guide/topics/connectivity/localonlyhotspot
On the latest versions it is unable to configure custom network name and password. My last argument for this was a try using Reflection API but no success with this. Class IWifiManager seems to be private for developers, this entity rules all the process of credentials generation

iOS:
It is impossible to create or activate a host spot in code, the public API does not provide such functionality. There is a private Apple API 'MFi' for accessory vendors that might or might not provide a similar functionality. Since it requires a vendor to enroll to this program and having approved by Apple being provided with API documents. I was not able to get any further information on this.

Conclusion:
It is still possible to implement the proposed logic on SDL core. There are plenty of custom made AOSP and rooted devices that may benefit from this functionality and the same comes with jail broken iOS devices also it may be useful for other hardware (which does not belong to Android or iOS realm). Though considering the comparatively small number of such devices I believe it is not feasable to implement this functionality at the moment having more important proposals at hand. The hot spot implemented on the head unit alone must be enough for the time being besides it makes this logic simpler and error proof.

yoooriii on 2 Jun 2020

Decision depends on following variables :
- ini file networkHostPriority
- ini file allowAccessPointSharing
- Current Vehicle NetworkingCapabilities : autoJoinWiFiSupported
- Current Vehicle NetworkingCapabilities : canHostWiFiNetwork
- Current Vehicle NetworkingCapabilities : dataFallbackSupported
- Current Vehicle NetworkingCapabilities : accessPointSupportsInternetAccess
- Current Vehicle NetworkingCapabilities : preferredNetworkHost
- Current Vehicle NetworkingCapabilities : allowAccessPointToBeShared
- Current Vehicle NetworkingCapabilities : wifiFrequencyBandsSupported (There should be intersection between Vehicle and Device values)
- Current Vehicle NetworkingCapabilities : wifiSpecsSupported (There should be intersection between Vehicle and Device values)
- Current Mobile NetworkingCapabilities : autoJoinWiFiSupported
- Current Mobile NetworkingCapabilities : canHostWiFiNetwork
- Current Mobile NetworkingCapabilities : dataFallbackSupported
- Current Mobile NetworkingCapabilities : accessPointSupportsInternetAccess
- Current Mobile NetworkingCapabilities : preferredNetworkHost
- Current Mobile NetworkingCapabilities : allowAccessPointToBeShared
- Current Mobile NetworkingCapabilities : wifiFrequencyBandsSupported (There should be intersection between Vehicle and Device values)
- Current Mobile NetworkingCapabilities : wifiSpecsSupported (There should be intersection between Vehicle and Device values)
- Status of Wifi connection (may be it should be postponed)

Some combinations of these parameters are just impossible but SDL should care about them anyway.

Consider use case :

ini : 'BOTH'
Vehicle:NetworkingCapabilities:canHost : true
Vehicle:NetworkingCapabilities:canJoinNetwork : true
Mobile:NetworkingCapabilities:canHost : true
Mobile:NetworkingCapabilities:canJoinNetwork : true
Mobile:NetworkingCapabilities:dataFallbackSupported : true
Mobile:NetworkingCapabilities:dataUsagePreference : VEHICLE
Vehicle:NetworkingCapabilities:preferredNetworkHost : MOBILE

In this case, OEM is trying to enforce AP placement of mobile as the preferred option (condition 8).
But the proposal says that SDL should choose VEHICLE because of conditions 6, 7.

Probably OEM may configure this via INI file. But INI file is not a dynamic entity.

At least preferred network most has different meanings in different use cases
- in NetworkCapabilities from HMI or Mobile: preferred network host
- in NetworkCa pabilities from SDL: chosen network host

Wifi frequencyBand supported also have different meanings:

in NetworkCapabilities from HMI or Mobile: list of available frequency bands
in NetworkCapabilities from SDL: chosen frequency band for communication establishing.

autoJoinnWIfiSupported is not applicable for a message from SDL.

Probably it is my personal opinion that bidirectional RPCs make things less explicit.
Main drawbacks:
- No ability to control RPC in a certain direction via policies
- Unable to make RPC application-specific (appID parameter will have no sense if it sent from Mobile)
- Issues with debugging.
  But Finally, I am OK to keep JoinNetwork bidirectional.
OK.
I would like to point out the following race conditions :

race1

There is a workaround in the proposal described in https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md#mobile-device-is-a-network-host diagram.
There is an important note :
HMI MUST send OnSystemCapabilityUpdated after Wifi connection event if NetworkCapabilities was not changed.
In another case following sequence possible :

race2

The root cause of the issue is that the placement of decision making is not in the same place as hardware control.

I can see possible issues with the following use cases

Between app registration and OnSystemCapabilitiesUpdate from HMI
Missing OnSystemCapabilitiesUpdate from HMI will prevent wifi connection for any further devices
If multiple apps available on one device for feature initialization there are no rules for SDL to choose one
No rules for SDL to reject JoinNetwork RPC that is not expected
If feature initialization failed, no requirements if SDL should try with another device or another app of the initial device

LuxoftAKutsan on 2 Jun 2020

@yoooriii Please see my comment which provided the basis for the agreed upon revisions to this proposal during the previous review:

Additional Information

Can either be a hotspot or a common, known WiFi connection
Android
- startLocalOnlyHotspot() - “The network created by this method will not have Internet access.”
- When creating a hot spot programmatically, the result will not allow clients to share the internet connection of the mobile device
- User could create an access point with internet access and the app could ask IVI to join
- User could set preferred WiFi network
iOS
- Unable to create an access point programmatically
- User could create an access point and the app could ask IVI to join
- User could set preferred WiFi network

joeygrover on 2 Jun 2020

The Steering Committee voted to keep this proposal in review until our next meeting, to allow the author time to respond to the feedback provided in the comments by the Project Maintainer.

theresalech on 3 Jun 2020

> The "minimal" approach appears to have removed the dynamic role-switching "BOTH

SDL configs do not contain BOTH option. Because it seems redundant in the "minimal" approach. OEM controls the way how to establish Wifi connection and it does not affect SDL configuration.

See this comment. Is it your intention to have the Steering Committee re-visit this approved feature component?

~~Yes, I would like to re-visit this solution in the scope of another technical approach in the minimal solution. As I already told this SDL configuration seems redundant to me.~~

The minimal approach does not remove BOTH ability. Dynamic role switching is still possible. But SDL plays the role of proxy here, but not decision-maker. So this configuration is redundant on the sdl_core side.

>We disagree that there is an issue with using bidirectional RPCs. See AppService related RPC's and OnSystemCapabilityUpdated notification. This comment should be removed from the proposal.

I agree that this statement redundant in the proposal but still would like to keep JoinVehicleNetwork and JoinMobileNetwork as separate RPC's.
It is not a critical point. But with separate RPC's Policy may give separate access for certain applications to each RPC.

Main approach uses OnSystemCapabilityUpdated with different filled parameters in different directions with different intentions.

Minimal approach one direction simple notification ReadyForWifiConnection to notify mobile that Vehicle is ready for mobile to create AP and ask the vehicle to connect.
And also there is an option to replace this new RPC with OnSystemRequest(WIFI_READY_TO_CONNECT)
Diagram created with OnSystemRequest(WIFI_READY_TO_CONNECT).Sorry for this inconsistency.
I feel these 2 options equipollent, but the only one should exist.

I mean that if OEM already implemented sharing Wifi SSID via OnSystemRequest with custom type, it will require fewer efforts to reimplement it using the Minimal approach solution. Of course this some kind of speculation.
I base my reasoning that already implemented sharing SSID logic may use SDL only as of the proxy. And minimal approach continues using SDL as a lightweight proxy, while the main approach puts decision making logic on SDL.
Propose to put in guidelines and proposal that HMI should send JoinNetwork or OnSystemRequest(WIFI_READY_TO_CONNECT)/ReadyForWifiConnection right after app registration.
This is an HMI application id. In the minimal approach as you can see HMI sends JoinNetwork, not to SDL core but particular application throw sdl_core.
~~Will add wifiSpecsSupported~~
Will modify ReadyForWifiConnection

<function name="ReadyForWifiConnection" functionID="ReadyForWifiConnectionID" messagetype="notification" since="x.x">
    <description>
      Notification from vehicle to mobile to inform that vehicle is ready to be WiFi client and requests WiFi connection with mobile as an access point.
    </description>

    <param name="wifiFrequencyBand" type="FrequencyBand"  mandatory="false">
      <description>

      </description>
    </param>
    <param name="wifiSpec" type="String"  mandatory="false">
      <description>
      </description>
    </param>
</function>

BTW, Not sure, that specifying wifiFrequencyBand, wifiSpec is possilbe in android\ios API while creating Wifi AP.

> Why was Device renamed to NetworkHost
We already have such an entity as Device. If we need to introduce enum that specifies if WifiAccess point will be on Vehicle or Mobile device, NetowkHost is a better name then Device from my perspective

If we ever want to differentiate between the app and the device in the future, we will either have to redefine a new enum with the same values, or use NetworkHost as the type, which will be awkward.

The use case is not clear for me. Could you please provide some kind of example.

OK
Sorry for the inconsistency. See point 8.
Intention to make application active for feature initialization is more complex if we will go deeper. The use case described in https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md#manual-wifi-connection

After Wifi disconnection and receiving OnSystemCapabilityUpdated with new values, SDL should choose one of the existing applications to establish a new Wifi connection.
This application names as active for feature initialization

LuxoftAKutsan on 8 Jun 2020

Hi @LuxoftAKutsan, please find our responses below.

1. This use-case appears to be correct. The "Mobile" is the user's preference. If the head unit is okay with either connection and the user is explicitly choosing to use the vehicle, the vehicle is used. It's not correct to say, "OEM is trying to enforce AP placement of mobile". If they were doing that they would have set MOBILE in the INI file. They set both, so they're not "enforcing" anything. The final decision if BOTH are available should be the user's.

Additionally, the proposal states that "These bullet points are just a suggestion, an OEM can determine the situation themselves."

2. Reusing data structs is an important effort into efficiency. There is no point creating more and more data structures if it is possible to reuse them. Every struct requires additional classes and conversions that add to the bloat. We should be aim to reduce this, not openly inflate it.

3. Resolved, with no action needed. JoinNetwork will remain bidirectional as stated.

4. Resolved, author to make following revision: Add additional EXTERNAL networkHost. This is because if the application allows sharing Wifi credentials for other mobile devices, other mobile devices should know that they are connecting to an external Wifi hotspot but not Vehicle one.

5. Regarding the first chart, we dont believe this is a valid race condition. Core should be tracking the status of the initial AP negotiation between the vehicle and device 1. Core should not consider device 2 for the AP role until app1/device 1 disconnects or the AP negotiation fails.

For chart 2, it seems part of the proper flow was added to not send OnSystemCapability updated until after the Vehicle had successfully connected to the mobile AP of device 1, this is as expected. With adding the EXTERNAL enum value we're also assuming that would replace VEHICLE in that capability. For the OnTransportEventUpdated timing issue, it should be possible to first send the OnSystemCapabilityUpdated RPC prior to sending the OnTransportEventUpdated packet. This would inform the libraries of where the network host is prior to it trying to connect to the IP/port of the core instance. This would allow the library to fist attempt to connect with the network host and subsequently connect to the ip/port of core and not introduce an additional flow, but only an additional prerequisite to connecting to the ip/port of core.

Minimal Approach Feedback
6. Can you explain how dynamic role switching works in the minimal approach?

7. Because we include the ability to dynamically determine who the network host is, trying to control that through policies will not be efficient. Determination of network host is based on capabilities of hardware and user preference, not specific apps. The feature should either be allowed for an app or not; If the IVI system wishes to predetermine who the network host is, that is included into the INI entry.

8. The only time that OnSystemCapability has been made to flow in a different direction is from Core to the HMI. Since this is a point of contention, it would be easier to simply include the NetworkingCapabilities supplied by the app in the RAI request into the OnAppRegistered notification sent from Core to the HMI instead. Then the OnSystemCapabilityUpdated notification keeps its original flow with original meaning; the capabilities supplied are meant to be the exact capabilities of the IVI system. Therefore, no additional notifications are necessary and the original solution works well.

9. I disagree that we should design our ideal solution around an assumption that doesn't have any supporting evidence. As we agreed to out of the workshop this is not the correct way to implement the feature. The idea of SDL as a proxy is not true and it contains many fully realized features and therefore is not an argument that has any validity.

10. I believe we discussed this before but starting the AP starting/joining process after registration does not ensure an app has up to date policies and the join network rpcs could be disallowed / allowed based on an outdated PT. We might want to mention the HMI should not send this message if it has recently received an UPDATING OnStatusUpdate rpc. Is there another way the HMI could verify Core PT is up to date?

11. Understood. I missed the HMI header when reviewing the section, my apologies.

12. Resolved, author to make following revision: Will modify ReadyForWifiConnection as noted in this comment.

13.
For example:

We use your enum NetworkHost with options MOBILE and VEHICLE.

Later, we add an RPC function like:

<function name="ChooseMobileOrVehicle">
</function>

On the original proposal, the parameter in that function would be:

<param name="choice" type="Device">

This makes sense. If we use your approaches, there are two options:

Re-define a new enum with the same values
Use

<param name="choice" type="NetworkHost">

(2) seems pretty awkward to me. For future proofing and reusability, we would ask that the enum name Device be preserved

Again this comes down to being responsible for our library implementation. For example, each of these enums will be loaded into memory at runtime on Java. So either we create a multitude of different enums that have similar values, or we reuse the enum with less than intuitive name across those use cases. Keeping this as Device is intuitive, general enough for future use cases, and doesn't hurt the current solution at all.

14. Resolved, author to make following revision:

<function name="OnServiceUpdate" messagetype="notification">
  <param name="encrypted" type="true" mandatory="false">
</function>

This change mentioned in the minimal approach should be added to the main approach method. Missing the encrypted parameter was an oversight from the original revision.

15. Resolved, author to make following revision: Author to update flow chart in minimal approach to use ReadyForWifiConnection instead of OnSystemRequest.

16. Resolved, we can continue conversation in Item 10.

Additional feedback to main solution
17. We noticed that the revision to the main proposal does not include BOTH in the .ini file update and uses an array to designate the priority of the access point. First, using a priority array was not a part of the agreed upon revisions. Second, how does this priority list work and when would Core choose the AP mode with a lesser priority? Finally, is the ini param update in the minimal solution supposed to be a priority array as well?

18. In the "Manual WiFi connection" section we notice a couple of things:

a. There is no mention of app activation as the agreed to as the trigger event for this feature during the workshop. Was this simply missed or intentional?

b. There is an event "WiFi Access Point is disconnected", can you explain this further? Why was the AP disconnected? By the user? Automatically by the code?

theresalech on 9 Jun 2020

The Project Maintainer, Luxoft, and Ford teams discussed the exhaustive effort that’s been spent on continually providing solutions for this proposal that are rebuked and revised from what’s previously been voted upon and agreed to by Steering Committee members. It was noted that this proposal is approximately 40 pages when printed, and without a clear understanding of both solutions presented, difficult for members to review and informatively vote. It was agreed that it would be beneficial if the authors and interested parties could stay more true to what’s been agreed to in the past, so that this proposal can get passed. It was also clarified that the solution provided in the “Alternatives Considered” section does not include what was previously voted upon and approved by the Steering Committee, and this needs to be remedied before the Steering Committee can be tasked with voting on a solution. It was stated that once this has been fixed, it seems the major difference from the approved revisions that were voted upon before is that the solution described in the “Alternatives Considered” section doesn't currently contain a clear process of defining who is the network host dynamically.

The Steering Committee voted to keep this proposal in review, so the author could review the PM’s feedback and work to stay more true to the previously agreed upon solution. The author should make sure the "Alternatives Considered" solution is still in line with the previously agreed upon revisions, and then provide clear information on what is different in the "Alternatives Considered" solution as compared with the existing solution.

theresalech on 10 Jun 2020

We propose to defer this proposal.

robinmk on 16 Jun 2020

Per the author's request, the Steering Committee voted to defer this proposal. The author can email [email protected] when they are able to dedicate the time and resources necessary to take further action on the proposal and bring it back under Steering Committee review.

theresalech on 17 Jun 2020

Closing as inactive. The issue will remain in a deferred status and unlocked so the author can notify the Project Maintainer when it is ready to be revisited.

theresalech on 7 Jul 2020

Sdl_evolution: [Deferred] SDL 0245 - WiFi Transport: Sharing SSID and password with Mobile Proxy

Most helpful comment

All 110 comments

Require Encryption for Password RPCs

Make feature for OEM apps only

Enable both Head Unit and Mobile devices to be Access Points

Join Network RPC

Determining which device should host the network

Potential Solution

Enable both Head Unit and Mobile devices to be Access Points

Requirements

RPC Flow

RPC Spec Changes

Networking Capabilities

preferredNetworkHost

allowAccessPointToBeShared

Join Network RPC

Determining which device should host the network

Additional Information

Potential Downsides

Android Permission Issue

iOS Entitlement Issues

OEM Apps Only vs All Apps

Networking Information Not Encrypted

Impact to Existing Code

Summary for #981 :

Key points :

Summary for #980 :

Key points:

Additional Information

Related issues