[RFC] P2P: Handling single channel concurrency

[Jithu Jance]

Hi Reinette,

Thanks for your suggestion. Please find my commments inline.

> It would be nice if there were some hooks available to enable user to
> have an opinion about the action being taken. The STA connection may (1)
> be automated and be requested without user's knowledge, (2) be requested
> by user not knowing that the current connection may be dropped, etc. For
> example, user may not want to be disconnected from the current WFD
> session with their TV when trying to send email at same time, user may
> prefer to defer sending the email. Just dropping the WFD session is a
> rather bad user experience in this example.

Agree with you. Sharing my thoughts on acheiving this user notification part. 
One option is to have a config file parameter which framework can set and user 
would be able to change that. This will allow user to decide to prefer STA over
P2P or P2P over STA. In addition to this, we may add a new reason code to GROUP_REMOVE
event to indicate that group has been removed due to frequency conflict. This way 
framework/user app can come to know about it and notify user. This policing is 
not run-time. But this probably can be attempted as a first step.


Another option. This is kind of a runtime decision making. But not sure whether this
is the right way to do it.

1. On attempting a STA connection, check whether there is a frequency conflict with any other
interface.
2. On detecting the frequency conflict following steps can be taken
	a) Disable the current STA network to avoid connection. supplicant won't try to connect until it is again
       enabled from the application.
        b) sent an event/notificaton to User space
            i)   User app/framework on getting event should ask user persmission to forgo P2P connection
            ii)  If user opts "no", the station config remains disabled and P2P connection stays as is.
            iii) If user opts "yes", the framework removes the p2p group and enables the STA config. Since network blob is enabled, 
                sta connection is again attempted and this time supplicant won't find a conflict since p2p interface doesn't exist.



Request opinion on above thoughts.





- Jithu Jance.




________________________________________
From: Reinette Chatre [reinette.chatre at intel.com]
Sent: Wednesday, January 04, 2012 12:02 AM
To: Jithu Jance
Cc: hostap at lists.shmoo.com
Subject: Re: [RFC] P2P: Handling single channel concurrency

Hi,

On Tue, 2011-12-27 at 03:15 -0800, Jithu Jance wrote:
> This patch attempts to handle the single channel concurrency scenario where we initially have a P2P connection and then a STA connection is attempted.
>
> As a first step, i tried implementing following things.
> 1. When STA connection is attempted, try to find whether there is any frequency conflict between any other interface.
> 2. If the conflicting interface is a P2P GO, announce channel switch in beacons and move the GO. /* Just a hook is provided. Functionality is not yet implemented */
> 3. If GO is not able to move the channel or the driver doesn't support the functionality, remove the P2P GO interface.
> 4. If the conflicting interface is a P2P Client, disconnect & remove the client interface.
>
>
> Request your opinion on the below patch.
>

It would be nice if there were some hooks available to enable user to
have an opinion about the action being taken. The STA connection may (1)
be automated and be requested without user's knowledge, (2) be requested
by user not knowing that the current connection may be dropped, etc. For
example, user may not want to be disconnected from the current WFD
session with their TV when trying to send email at same time, user may
prefer to defer sending the email. Just dropping the WFD session is a
rather bad user experience in this example. In any case if such a
drastic action is taken I do think we need to give user an opportunity
to make the decision. Please note that I am not proposing policy inside
wpa_supplicant, but it seems like we need to start looking into making
hooks available to support this.

Reinette