search

smartdevicelink / sdl_evolution

Tracking and proposing changes to SDL's public APIs.
https://smartdevicelink.github.io/sdl_evolution/
BSD 3-Clause "New" or "Revised" License
33 stars 122 forks source link

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

Closed theresalech closed 4 years ago

theresalech commented 5 years ago

Hello SDL community,

The review of the revised proposal "SDL 0245 - WiFi Transport: Sharing SSID and password with Mobile Proxy" begins now and runs through June 2, 2020. Previous reviews of this proposal took place July 31 - August 20, 2019, September 25 - October 15, 2019, October 30 - November 18, 2019, January 15 - January 28, 2020, February 19 - February 25, 2020, and April 15 - April 21, 2020. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/799

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you, Theresa Lech

Program Manager - Livio theresa@livio.io

theresalech commented 5 years ago

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:

theresalech commented 5 years ago

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.

kshala-ford commented 5 years ago

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:

theresalech commented 5 years ago

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

theresalech commented 4 years ago

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.

joeljfischer commented 4 years ago

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

ashwink11 commented 4 years ago

  1. Sure, I will include it.

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

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

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

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

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

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

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

  3. The pop up is shown immediately after the user attempts to launch an App.

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

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

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

Jack-Byrne commented 4 years ago

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

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

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

  1. Have we ever discussed what happens if a user disables/enables wifi on their mobile device after an app has already registered?
ashwink11 commented 4 years ago

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.

joeygrover commented 4 years ago

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.

ashwink11 commented 4 years ago

Sequence diagram if IVI is Wi-Fi access point ivi_ap

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

  1. An SDL App registers on IVI. This app supports WiFi automatic connection and hence sends DeviceInfo.wifiConfigurationInfo.autoJoinWiFiSupported = true.
  2. IVI shares Wi-Fi access point info with SDL core using OnWiFiTransportStatusUpdate notification.
  3. The user attempts to launch an SDL app that supports WiFi automatic connection.
  4. IVI sends System request with request type WIFI_CONNECTION_REQ to SDL core and which is then forwarded to the proxy.
  5. The proxy sends GetWiFiNetworkInfo to get WiFi SSID, password and security type.
  6. 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

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

Edit: added descriptions

ashwink11 commented 4 years ago
  1. & 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:

Transport Strings Attributes/description
IAP_USB IAP protocol + USB transport
IAP_USB_HOST_MODE IAP protocol + USB transport + Host mode
IAP_USB_DEVICE_MODE IAP protocol + USB transport + device mode
IAP_CARPLAY IAP protocol + CarPlay
SPP_BT Serial port profile + BT transport

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

Transport Strings Attributes/description
TCP_WIFI_AP_MODE TCP + WiFi transport + access point mode
TCP_WIFI_STA_MODE TCP + WiFi transport + station mode

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

Transport Strings Attributes/description
TCP_WIFI_AP_MODE TCP + WiFi transport + Phone in access point mode
TCP_WIFI_STA_MODE TCP + WiFi transport + Phone in station mode

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.

  1. Agreed. I will remove this point.

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

  1. Sure, I will add it.

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

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

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

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

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

  1. I will get back to you on this point.

ashwink11 commented 4 years ago
  1. 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.

issue no. Status Comment
1 Closed Need update from author
2 Open Waiting for inputs from PM
3 Open Waiting for inputs from PM
4 Open Waiting for inputs from PM
5 Open Waiting for inputs from PM
6 Open Waiting for inputs from PM
7 Open Waiting for inputs from PM
8 Closed Need update from author
9 Open Waiting for inputs from PM
10 Closed No change
11 Closed Need update from author
12 Closed Need update from author
13 Open Waiting for inputs from PM
14 Open Waiting for inputs from PM
15 Open Waiting for inputs from PM
16 No issue No issue
17 Closed Need update from author
18 Open Waiting for inputs from PM
19 Closed Need update from author
20 Open Waiting for inputs from PM
21 Open Waiting for inputs from PM
22 Open Waiting for inputs from PM
23 Open Waiting for inputs from PM
theresalech commented 4 years ago

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.

joeljfischer commented 4 years ago

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

kshala-ford commented 4 years ago

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

ashwink11 commented 4 years ago

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.

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

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

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

issue no. Status Comment
1 Closed Need update from author
2 Open Waiting for inputs from PM
3 Closed No change
4 Open Waiting for inputs from PM
5 Open Waiting for inputs from PM
6 Open Waiting for inputs from PM
7 Open Waiting for inputs from PM
8 Closed Need update from author
9 Open Waiting for inputs from PM
10 Closed No change
11 Closed Need update from author
12 Closed Need update from author
13 Open Waiting for inputs from PM
14 Open Waiting for inputs from PM
15 Open Waiting for inputs from PM
16 No issue No issue
17 Closed Need update from author
18 Open Waiting for inputs from PM
19 Closed Need update from author
20 Open Waiting for inputs from PM
21 Open Waiting for inputs from PM
22 Open Waiting for inputs from PM
23 Open Waiting for inputs from PM
theresalech commented 4 years ago

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

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:

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?

issue no. Status Comment
1 Closed Need update from author
2 Open Waiting for inputs from author
3 Closed No change
4 Open Waiting for inputs from author
5 Open Waiting for inputs from author
6 Open Waiting for inputs from author
7 Closed Need update from author
8 Closed Need update from author
9 Open Waiting for inputs from author
10 Closed No change
11 Closed Need update from author
12 Closed Need update from author
13 Open Waiting for inputs from author
14 Open Waiting for inputs from author
15 Open Waiting for inputs from author
16 Open Waiting for inputs from author
17 Closed Need update from author
18 Open Waiting for inputs from author
19 Open Waiting for inputs from author
20 Open Waiting for inputs from author
21 Open Waiting for inputs from author
22 Open Waiting for inputs from author
23 Open Waiting for inputs from author
24 Open Waiting for inputs from author

edit: added no. 24 to table

kshala-ford commented 4 years ago
  1. 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.

ashwink11 commented 4 years ago

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

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

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

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

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

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

  2. I don't think it would work without entitlements.

Update the table below.

issue no. Status Comment
1 Closed Need update from author
2 Open Waiting for inputs from PM
3 Closed No change
4 Open Waiting for inputs from PM
5 Open Waiting for inputs from PM
6 Open Waiting for inputs from PM
7 Closed Need update from author
8 Closed Need update from author
9 Open Waiting for inputs from PM
10 Closed No change
11 Closed Need update from author
12 Closed Need update from author
13 Open Waiting for inputs from PM
14 Open Waiting for inputs from PM
15 Open Waiting for inputs from PM
16 Open Waiting for inputs from PM
17 Closed Need update from author
18 Open Waiting for inputs from PM
19 Closed Need update from author
20 Open Waiting for inputs from author
21 Closed Need update from author
22 Open Waiting for inputs from PM
23 Open Waiting for inputs from PM
24 Open Waiting for inputs from PM
LuxoftAKutsan commented 4 years ago

Hi, some more points from Luxoft side:

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

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

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

  4. 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. image 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.
theresalech commented 4 years ago

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.

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:

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

15.

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

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.

issue no. Status Comment
1 Closed Need update from author
2/13 Open Waiting for inputs from author
3 Closed No change
4/5 Open Waiting for inputs from author
6 Open Waiting for inputs from author
7 Closed Need update from author
8 Closed Need update from author
9 Open Waiting for inputs from author
10 Closed No change
11 Closed Need update from author
12 Closed Need update from author
14 Open Waiting for inputs from author
15 Open Waiting for inputs from author
16 Open Waiting for inputs from author
17 Closed Need update from author
18 Open Waiting for inputs from author
19 Closed Need update from author
20 Open Waiting for inputs from author
21 Closed Need update from author
22 Closed No change
23 Open Waiting for inputs from author
24 Open Waiting for inputs from author
25 Open Waiting for inputs from author
26 Open Waiting for inputs from author
27 Open Waiting for inputs from author
28 Open Waiting for inputs from author
theresalech commented 4 years ago

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 commented 4 years ago

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

theresalech commented 4 years ago

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.

joeygrover commented 4 years ago

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:

  1. HMI sends core an OnSystemCapabilities notification that includes the NetworkingCapabilities of the head unit
  2. App sends RegisterAppInterface with new NetworkingCapabilities param as part of the DeviceInfo struct.
  3. ~Head unit~ Core sends RegisterAppInterface response
  4. If app has permission to use feature, head unit uses info supplied in NetworkingCapabilities and its INI config file to determine best network setup.
  5. 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.
  6. 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.
  7. 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

RPC Flow

rpc_flow.png

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.

Additional Information

Potential Downsides

Android Permission Issue

iOS Entitlement Issues

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

AByzhynar commented 4 years ago

@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>
ashwink11 commented 4 years ago

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?

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

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

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

joeygrover commented 4 years ago

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.

AByzhynar commented 4 years ago

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

joeygrover commented 4 years ago

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

AByzhynar commented 4 years ago

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

joeygrover commented 4 years ago

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

LuxoftAKutsan commented 4 years ago

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.

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?

Jack-Byrne commented 4 years ago

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.

  1. Core should use the most recent capabilities received from the HMI along with the app's network capabilities sent at registration.

  2. Ok that is a good idea.

  3. They will not be able to establish a wifi connection.

  4. Either would work fine but i believe the device handle from the transport level is the main method in core for detecting the device.

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

  1. Can an app unsubscribe from display capabilities? I don't think it can. Maybe the same behavior should apply to the networking capabilities.

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

  3. I think that is up to the HMI implementation.

  4. Yes I think it should be sent but most cases nothing should happen because there is already an established access point and wifi connection.

  5. Yes it should allow the connection. In the case of auto reconnection there does not need to be a join network.

  6. No not needed unless the wifi credentials changed or auto reconnect is false.

  7. Yes i think core should cache the first networking capabilities received from mobile.

  8. Open to suggestions, but here is mine:

[AccessPoint]
;NetworkHost = MOBILE, VEHICLE, ALL, or NONE
NetworkHost = ALL
ashwink11 commented 4 years ago

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

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

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

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

  1. Please confirm the below behavior.
Internet Connectivity available with Wi-Fi Access point Responsiblity
Mobile device IVI Mobile OS use the internet from mobile network
IVI IVI Mobile OS use the internet from connected Wi-Fi access point
Mobile device Mobile Device Mobile OS use the internet from mobile network

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 commented 4 years ago

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

LuxoftAKutsan commented 4 years ago

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

theresalech commented 4 years ago

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 commented 4 years ago

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

LuxoftAKutsan commented 4 years ago

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 :

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

theresalech commented 4 years ago

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.

LuxoftAKutsan commented 4 years ago

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 :

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:

theresalech commented 4 years ago

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:

  1. Update proposal to reflect the solution in https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-588434670 as you mentioned.
  2. 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.

LuxoftAKutsan commented 4 years ago

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

theresalech commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

LuxoftAKutsan commented 4 years ago

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

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

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

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

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

  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.

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.

theresalech commented 4 years ago

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.