Patent Description:
Consumers increasingly expect their computing devices to remain connected to network-based services, regardless of their location. However, cellular services such as <NUM> LTE and <NUM> may provide less than optimal connections for certain locations that are indoors, far from cell towers, and/or otherwise obstructed. Technologies such as the Wireless Broadband Alliance's (WBA) OpenRoaming™ use a federation-based framework to allow consumers to seamlessly roam onto Wi-Fi networks.

User-defined networks (UDNs) allow private networks to be established in a shared or public networking infrastructure. Using UDNs, a private network may include a set of users and devices that span multiple virtual local area networks (VLANs) and/or wireless LANs. The private network can be manually configured or automatically configured, e.g., based on location. Thus, service discovery, link-local multicast (LLM), broadcast traffic, and optionally unicast traffic may be contained within the private network.

<CIT> describes, according to its abstract, a method for providing access to wireless networks which may include receiving, by a wireless network access provider from a user device, a request to access a wireless network. The method may include obtaining data representing a policy applicable to the access request, sending the access request, augmented with the policy, to an identity provider associated with the user and having no pre-existing relationship with the access provider, and receiving, from the identity provider, an access request response indicating whether or not the policy is met. The method may include communicating, to the wireless device, an indication that the access request has been accepted, if the policy is met, or an indication that the access request has been rejected, if the policy is not met. The access provider and identity provider may be members of an identity and access federation that communicate over a dynamically established secure connection.

One embodiment presented in this disclosure is a method of automated grouping of client devices for a user-defined network (UDN). The method comprises receiving, from a client device, an authentication request to join an access provider network. The authentication request includes a unique identifier of the client device for a federation-based network. The method further comprises transmitting the unique identifier to a UDN cloud, and transmitting the authentication request to an identity provider. The method further comprises receiving, responsive to the identity provider authenticating the authentication request, a list of one or more UDNs from the UDN cloud that are associated with the unique identifier. The method further comprises joining the client device with one or more other client devices present on the access provider network listing a same UDN.

Another embodiment presented in this disclosure is a network device comprising one or more computer processors configured to perform an operation comprising receiving, from a client device, an authentication request to join an access provider network. The authentication request includes a unique identifier of the client device for a federation-based network. The operation further comprises transmitting the unique identifier to a UDN cloud, and transmitting the authentication request to an identity provider. The operation further comprises receiving, responsive to the identity provider authenticating the authentication request, a list of one or more UDNs from the UDN cloud that are associated with the unique identifier. The operation further comprises joining the client device with one or more other client devices present on the access provider network listing a same UDN.

Another embodiment presented in this disclosure is a computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith. The computer-readable program code is executable by one or more computer processors to perform an operation comprising receiving, from a client device, an authentication request to join an access provider network. The authentication request includes a unique identifier of the client device for a federation-based network. The operation further comprises transmitting the unique identifier to the a UDN cloud, and transmitting the authentication request to an identity provider. The operation further comprises receiving, responsive to the identity provider authenticating the authentication request, a list of one or more UDNs from the UDN cloud that are associated with the unique identifier. The operation further comprises joining the client device with one or more other client devices present on the access provider network listing a same UDN.

Target deployments for user-defined networks (UDNs) include locations where a personalized, private network should be established in a shared or public networking infrastructure. Some example locations include dormitories, universities, multi-dwelling units, hospitals, hotels, entertainment venues, and so forth.

A user may generally access all of the devices joined to the UDN, and may extend access to the UDN by sending invitations to other users. By creating a logical grouping of users and devices through the UDN, only those devices within the UDN may see (and may advertise services to) each other.

UDNs are typically defined by grouping Media Access Control (MAC) addresses of the devices as an identifier. In some cases, a user of the UDN must manually search for the MAC address(es) of the devices, and must use a specialized application, to enter the MAC address(es). However, due to privacy concerns, devices may intermittently change their MAC addresses (e.g., using MAC randomization), which would cause access of the device to the UDN to be disrupted. For example, if a user registers a device with the UDN using a first Service Set Identifier (SSID), and later tries to access the UDN using another SSID, the user will be unable to access the UDN if MAC randomization had been executed on the device before joining the second SSID.

Technologies such as OpenRoaming™ permit client devices to roam to different network access providers without requiring repeated logins or authentications. In some cases, identity providers may seek to offer additional services beyond roaming, such as providing network-based (e.g., cloud-based) services to the client devices.

In embodiments described herein, a method is disclosed for automated grouping of client devices for a UDN. The authentication request includes a unique identifier of the client device that is known by the federation-based network. The method further comprises transmitting the unique identifier to a UDN cloud and transmitting the authentication request to an identity provider. The method further comprises receiving, responsive to the identity provider authenticating the authentication request, a list of one or more UDNs from the UDN cloud that are associated with the unique identifier. The method further comprises joining, responsive to determining that one or more other devices on the access provider network belong to the same UDN, the client device with the other device(s) belonging to the same UDN.

Beneficially, using the method may make unnecessary the manual configuration of UDN and may support client devices using MAC randomization. Additionally, UDNs may be managed and moved across different networks by using the federation-based network (e.g., an OpenRoaming™ network) as the source of UDN-grouping information.

<FIG> is a diagram <NUM> illustrating connections of a client device <NUM> to a federation-based network <NUM> while roaming, according to one or more embodiments. The diagram <NUM> represents an example sequence of usage of a client device <NUM> by a user. For example, the sequence may represent a work trip of the user.

The client device <NUM> may be implemented in any form suitable for wireless networking. In some embodiments, the client device <NUM> is implemented as a mobile computing device, such as a laptop computer, a tablet, a smartphone, or a smart wearable device. In other embodiments, the client device <NUM> may be a computing device integrated into a vehicle.

At the beginning of the sequence, the user is at home <NUM>-<NUM> and the client device <NUM> is wirelessly connected to a home network (e.g., a Wi-Fi network) providing accessibility to an external network, such as a local area or local access network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet). While the user is driving <NUM>-<NUM> a car, the client device <NUM> is wirelessly connected to a cellular network, such as a <NUM> LTE or <NUM> cellular network. When the user arrives at a corporate office <NUM>-<NUM>, the client device <NUM> roams from the cellular network to a Wi-Fi network operated by the corporate office <NUM>-<NUM>. The user returns to the car to conduct a customer call <NUM>-<NUM>, and the client device <NUM> reconnects to the cellular network when out of range of the Wi-Fi network. The client device <NUM> later roams to different Wi-Fi networks when the user visits a branch office <NUM>-<NUM>, a coffee shop <NUM>-<NUM>, and a hotel <NUM>-<NUM>.

When roaming to the different Wi-Fi networks (e.g., at the corporate office <NUM>-<NUM>, the branch office <NUM>-<NUM>, the coffee shop <NUM>-<NUM>, and the hotel <NUM>-<NUM>), the client device <NUM> uses a federation-based network <NUM> to access the external network. The federation-based network <NUM> may be implemented using any standardized and/or proprietary techniques and protocols. For example, the federation-based network <NUM> may be compliant with OpenRoaming™.

The federation-based network <NUM> comprises a plurality of access providers <NUM> (also referred to as "access network providers") providing wireless connectivity for the client device <NUM> using, e.g., access points, wireless LAN controllers, and so forth. Some non-limiting examples of the access providers <NUM> include enterprise access providers <NUM> (e.g., employers, manufacturing facilities), consumer access providers <NUM> (e.g., hotels, retailers), public access providers <NUM> (e.g., airports, universities, venues), and so forth.

The federation-based network <NUM> comprises a plurality of identity providers <NUM> that operate to create, maintain, and/or manage identity information for users and that provide authentication services within the federation-based network <NUM>. Some non-limiting examples of the identity providers <NUM> include cloud providers <NUM> (e.g., vendors providing scalable computing resources), service providers <NUM> (e.g., telecommunications companies, utilities), and device manufacturers <NUM>. By using the identity providers <NUM> to authenticate the user, the client device <NUM> may roam to the different access providers <NUM> without requiring repeated logins or authentications from the user.

<FIG> is a diagram <NUM> illustrating a sequence for connection of a client device <NUM> to a federation-based network, according to one or more embodiments. The features illustrated in the diagram <NUM> may be used in conjunction with other embodiments, for example, illustrating connection of the client device <NUM> with an access provider <NUM> at any of the corporate office <NUM>-<NUM>, the branch office <NUM>-<NUM>, the coffee shop <NUM>-<NUM>, or the hotel <NUM>-<NUM> illustrated in <FIG>.

In the diagram <NUM>, an access provider <NUM> (one example of the access providers <NUM> of <FIG>) transmits a beacon <NUM> announcing one or more requirements for connecting the client device <NUM> to the access provider <NUM>. The beacon <NUM> may be implemented in any suitable form, such as an IEEE <NUM>. 11u beacon. In some embodiments, the beacon <NUM> indicates that the client device <NUM> must provide a private identification for the user. In other embodiments, the beacon <NUM> indicates that the client device <NUM> must provide only a public identification.

The client device <NUM> attaches <NUM> to the access provider <NUM> responsive to the beacon <NUM> (that is, the client device <NUM> establishes a connection with the access provider <NUM>), and the access provider <NUM> begins authentication of the user, e.g., via the Extensible Authentication Protocol (EAP) process, by communicating one or more acceptable credential types <NUM> to the client device <NUM>. The client device <NUM> may search a list of profiles stored thereon and may automatically select an identity <NUM> corresponding to an acceptable credential type <NUM> (e.g., a token, certificate, username/password, SIM, etc.) and that best matches the one or more requirements that had been specified by the access provider <NUM> (e.g., via the beacon <NUM>). In some embodiments, the identity <NUM> comprises elements of a Uniform Resource Locator (URL), such as a domain name. The client device <NUM> may select a best match using any suitable techniques.

The client device <NUM> provides the selected identity <NUM> to the access provider <NUM>, and the access provider <NUM> contacts a Domain Name Service (DNS) server <NUM> using the identity <NUM>. As shown in the diagram <NUM>, the identity <NUM> selected by the client device <NUM> is "bob@newco. com", which may be a public identity or a private identity responsive on the beacon <NUM> transmitted by the access provider <NUM>. The access provider <NUM> looks up <NUM> "newco. com" with the DNS server <NUM>. Using the result from the DNS server <NUM>, the access provider <NUM> sets up an encrypted and authenticated Transport Layer Security (TLS) tunnel <NUM> to an identity provider <NUM> (one example of the identity providers <NUM> of <FIG>) corresponding to the selected identity <NUM>. The identity provider <NUM> provides an EAP authorization <NUM> using Remote Authentication Dial In User Service (RADIUS) attributes to the access provider <NUM>, and the access provider <NUM> provides an EAP authorization <NUM> to the client device <NUM> using EAP over LANs (EAPoL).

<FIG> is a diagram <NUM> illustrating onboarding client devices <NUM>-<NUM>, <NUM>-<NUM> to a user-defined network (UDN) <NUM>, according to one or more embodiments. The features illustrated in the diagram <NUM> may be used in conjunction with other embodiments. For example, the client devices <NUM>-<NUM>, <NUM>-<NUM>, the access provider <NUM>, and the identity provider <NUM> of <FIG> may be respective examples of the client device <NUM>, the access providers <NUM>, and the identity providers <NUM> of <FIG>.

In the diagram <NUM>, the client devices <NUM>-<NUM>, <NUM>-<NUM>, and the identity provider <NUM> are connected to the access provider <NUM> via respective communicative links <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>. Each of the client devices <NUM>-<NUM>, <NUM>-<NUM>, the access provider <NUM>, and the identity provider <NUM> may be respectively implemented as one or more computing devices in any suitable form(s). For example, the client devices <NUM>-<NUM>, <NUM>-<NUM> may be implemented as mobile computing devices of one or more users, while each of the access provider <NUM> and the identity provider <NUM> may be implemented as one or more server computers. In some embodiments, the access provider <NUM> represents a network of multiple computing devices. For example, a UDN management module <NUM> of the access provider <NUM> may be implemented in a manager computing device that is separate from other computing device(s) of the access provider <NUM>.

Each of the client devices <NUM>-<NUM>, <NUM>-<NUM>, the access provider <NUM>, and the identity provider <NUM> comprises a respective one or more computer processors <NUM>, <NUM>, <NUM> and a respective memory <NUM>, <NUM>, <NUM>. The one or more computer processors <NUM>, <NUM>, <NUM> may be implemented in any suitable form, such as a general purpose microprocessor, a controller, an application-specific integrated circuit (ASIC), and so forth. The memory <NUM>, <NUM>, <NUM> may include a variety of computer-readable media selected for their size, relative performance, or other capabilities: volatile and/or non-volatile media, removable and/or non-removable media, etc..

Collectively, the access provider <NUM> and the identity provider <NUM> may represent one example of the federation-based network <NUM> of <FIG>, and may be implemented using one or more networks of any suitable types, such as a public network (e.g., the Internet), a local area network (LAN), a wide area network (WAN), and/or a wireless network. The communicative links <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> may have any suitable implementation, such as copper transmission cable(s), optical transmission fiber(s), wireless transmission, router(s), firewall(s), switch(es), gateway computer(s), and/or edge server(s). In some embodiments, the communicative links <NUM>-<NUM>, <NUM>-<NUM> are exclusively wireless communicative links.

The access provider <NUM> generally includes networking hardware that is located in proximity to the client devices <NUM>-<NUM>, <NUM>-<NUM> and provides wireless connectivity (e.g., via WiFi) for the client devices <NUM>-<NUM>, <NUM>-<NUM>. The access provider <NUM> may represent one or more types of devices, such as access points (APs), switches, routers, wireless LAN controllers (WLCs), policy engines, software-defined networking (SDN) controllers, and so forth.

In some embodiments, the access provider <NUM> advertises its support for the automated grouping of the client devices <NUM>-<NUM>, <NUM>-<NUM> into the UDN <NUM>. For example, the access provider <NUM> may advertise the support responsive to receiving a query from the client devices <NUM>-<NUM>, <NUM>-<NUM>. In some embodiments, the query complies with Access Network Query Protocol (ANQP). In some embodiments, the access provider <NUM> advertises support for the federation-based network, as well as for the automatic grouping, using new ANQP elements.

Beneficially, the client devices <NUM>-<NUM>, <NUM>-<NUM> may preferentially select the access provider <NUM> that advertises support for the automated grouping of the client devices <NUM>-<NUM>, <NUM>-<NUM>. For example, the client devices <NUM>-<NUM>, <NUM>-<NUM> may scan for available networks and rate the access provider <NUM> higher due to the advertising support.

The identity provider <NUM> generally provides authentication of the client devices <NUM>-<NUM>, <NUM>-<NUM> for onboarding to the UDN <NUM>. As discussed above, some examples of the identity provider <NUM> include cloud providers, service providers, and device manufacturers. The identity provider <NUM> may use any suitable authentication protocols, such as OAuth, Remote Authentication Dial-In User Service (RADIUS), Security Assertion Markup Language (SAML), and so forth.

The memory <NUM>, <NUM>, <NUM> may include one or more modules for performing various functions described herein. In one embodiment, each module includes program code that is executable by the respective one or more computer processors <NUM>, <NUM>, <NUM>. In another embodiment, each module is partially or fully implemented in hardware (i.e., circuitry) or firmware of the client devices <NUM>-<NUM>, <NUM>-<NUM>, the access provider <NUM>, and/or the identity provider <NUM> (e.g., as circuitry within the one or more computer processors <NUM>, <NUM>, <NUM>). However, other embodiments of the diagram <NUM> may include modules that are partially or fully implemented in other hardware or firmware, such as hardware or firmware included in one or more other computing devices connected with the access provider <NUM>, and so forth. Stated another way, the overall functionality of the one or more modules may be distributed among other devices of the diagram <NUM>.

As shown, the memory <NUM> of each of the client devices <NUM>-<NUM>, <NUM>-<NUM> comprises a messaging module <NUM> and a MAC randomizer module <NUM>, the memory <NUM> of the identity provider <NUM> comprises an identity services module <NUM>, and the access provider <NUM> comprises a UDN management module <NUM>.

The identity services module <NUM> generally operates to create, maintain, and/or manage identity information for users and/or for the associated client devices <NUM>-<NUM>, <NUM>-<NUM>. The identity services module <NUM> may further provide authentication services using the access provider <NUM>. In some embodiments, the identity services module <NUM> provides a credential used to authenticate a user for accessing a network-based service. The credential may be implemented in any suitable form, such as a secure token that is unique for a particular session with the user. In some embodiments, the secure token comprises a value provided by the identity provider <NUM>, an identifier of the identity provider <NUM>, and/or a value provided by the provider of the network-based service security.

Each client device <NUM>-<NUM>, <NUM>-<NUM> includes a profile <NUM> that is associated with the user of the client device <NUM>-<NUM>, <NUM>-<NUM>. Each profile <NUM> includes one or more selectable identities for connecting to the federation-based network. For example, a user may have an employer-provided identity and one or more personal identities. Each profile <NUM> may allow one or more services, policies, capabilities, features, etc. that are applied when the profile <NUM> is selected. For example, additional security service(s) may be applied for an employer-provided identity than for a personal identity. The one or more services, policies, capabilities, features, etc. may be selected and/or purchased directly by the user, or may be offered directly by the access provider <NUM> to the user.

Each profile <NUM> may include any other suitable information, such as a username and/or personal information. In some embodiments, the profile <NUM> includes a user-friendly device name, a unique identifier <NUM> for each device associated with (and managed by) the user, and/or a list of one or more UDNs associated with the device (e.g., associated with the unique identifier <NUM>). In some embodiments, the unique identifier <NUM> comprises a serial number assigned to the client device <NUM>-<NUM>, <NUM>-<NUM>.

In some embodiments, the identity services module <NUM> may store an inventory of client devices <NUM>-<NUM>, <NUM>-<NUM> associated with the user. Using the inventory of client devices <NUM>-<NUM>, <NUM>-<NUM>, the user may establish different UDN groupings such as business and personal UDNs, and may access each of the UDNs using the same profile <NUM>. Additionally, the inventory of client devices <NUM>-<NUM>, <NUM>-<NUM> may be updated to limit access by certain client devices <NUM>-<NUM>, <NUM>-<NUM>, such as when the client devices <NUM>-<NUM>, <NUM>-<NUM> have unauthorized use, or are lost or stolen.

The UDN management module <NUM> performs supervisory and/or maintenance functions for the UDN <NUM>. In some embodiments, the identity provider <NUM> creates the UDN <NUM> responsive to receiving a request from a client device <NUM>-<NUM>, <NUM>-<NUM>, and adds the requesting client device <NUM>-<NUM>, <NUM>-<NUM> to the UDN <NUM>. The identity provider <NUM> propagates the information about the created UDN <NUM> to the UDN management module <NUM>, where it is stored and updated as appropriate.

In some embodiments, the UDN management module <NUM> maintains a list of one or more UDNs associated with each identity. The list of the one or more UDNs may also be stored by the identity provider <NUM> separate from the UDN management module <NUM>, e.g., when the UDN management module <NUM> is implemented in a separate computing device. After the client device <NUM>-<NUM> is authenticated, the UDN management module <NUM> queries for the list of UDN(s) associated with the client device <NUM>-<NUM>. The UDN management module <NUM> receives the list of UDN(s) from the identity provider <NUM> through the UDN cloud (e.g., UDN cloud <NUM> shown in <FIG>). The list of UDN(s) is stored by the UDN management module <NUM>.

A similar process may be performed for the client device <NUM>-<NUM>. After successful authentication of the client device <NUM>-<NUM>, the access provider <NUM> (e.g., the UDN management module <NUM>) queries the list of UDN(s) associated with the client device <NUM>-<NUM>, receives the list of UDN(s) from the identity provider <NUM> and stores the list of UDN(s) in the UDN management module <NUM>.

When the UDN management module <NUM> finds a matching UDN definition in the lists received for the client devices <NUM>-<NUM>, <NUM>-<NUM>, the UDN management module will automatically form the UDN <NUM> (e.g., creates a local instance of the UDN <NUM> using the MAC addresses of the client devices <NUM>-<NUM>, <NUM>-<NUM> and the identifier <NUM>) and places the client devices <NUM>-<NUM>, <NUM>-<NUM> inside the UDN <NUM>.

Beneficially, while the access provider <NUM> receives the MAC address of the client device <NUM>-<NUM>, <NUM>-<NUM>, in some embodiments the MAC address is not transmitted to the federation-based network or to the identity provider <NUM> when joining the client device <NUM>-<NUM>, <NUM>-<NUM> to the UDN <NUM>. In this way, the user may have improved privacy as the various network devices are unable to track locations, lengths of time used, etc. using the user's MAC address(es).

Further, as discussed above, some implementations of the client devices <NUM>-<NUM>, <NUM>-<NUM> may intermittently change the MAC address presented to the access provider <NUM>. For example, the client devices <NUM>-<NUM>, <NUM>-<NUM> each include a MAC randomizer module <NUM> that randomizes the MAC address of the respective client device <NUM>-<NUM>, <NUM>-<NUM> according to any suitable techniques. In other embodiments, the MAC addresses of the client devices <NUM>-<NUM>, <NUM>-<NUM> may be intermittently altered without randomization.

Ordinarily, changing the MAC address of the client devices <NUM>-<NUM>, <NUM>-<NUM> would disrupt access to the UDN <NUM>, possibly requiring a manual reconfiguration. However, by using the identifier <NUM> associated with the federation-based network, the access provider <NUM> may ensure continued access of the client devices <NUM>-<NUM>, <NUM>-<NUM> to the UDN <NUM> despite any changes to the MAC addresses.

In some embodiments, the system illustrated in the diagram <NUM> may also support the ad hoc joining of client devices <NUM>-<NUM>, <NUM>-<NUM> to the UDN <NUM>. For example, two colleagues at a conference may wish to set up a UDN for directed P2P messaging, file sharing, etc. with each other. In one example sequence, the client devices <NUM>-<NUM>, <NUM>-<NUM> are authenticated using the respective identifiers <NUM> (e.g., through the access provider <NUM> at the site of the conference). The user of the client device <NUM>-<NUM> may create the UDN <NUM> using the techniques discussed above. The user of the client device <NUM>-<NUM> may then use the messaging module <NUM> to send an invitation to the user of the client device <NUM>-<NUM>.

The messaging module <NUM> may be implemented in any suitable form for transmitting an invitation to the UDN <NUM>. Some non-limiting examples of the messaging module <NUM> include an email client, a dedicated messaging client, and a social networking client. Further, the invitation may be provided to the client device <NUM>-<NUM> in any suitable format, such as a hyperlink. Beneficially, the messaging module <NUM> may be implemented using application(s) on the client devices <NUM>-<NUM>, <NUM>-<NUM> that are already used by the user (e.g., without requiring use of a specialized application).

When the user of client device <NUM>-<NUM> accepts the invitation, the client device <NUM>-<NUM> transmits an authentication request (with the identifier <NUM>) that is transmitted to the UDN management module <NUM>. The UDN management module <NUM> may transmit the list of UDN(s) associated with the identifier to the access provider <NUM>, and the access provider <NUM> may join the client device <NUM>-<NUM> to the UDN <NUM>. Because the UDN <NUM> is defined over the identifiers <NUM> of the client devices <NUM>-<NUM>, <NUM>-<NUM>, the client devices <NUM>-<NUM>, <NUM>-<NUM> may migrate to different access providers <NUM> (e.g., at locations different from the site of the conference) while providing a same experience.

<FIG> is a method <NUM> of creating a UDN using an authenticated client device, according to one or more embodiments. The method <NUM> may be used in conjunction with other embodiments, e.g., performed using a combination of the access provider <NUM>, and the identity provider <NUM> of <FIG>.

The method <NUM> begins at block <NUM>, where a client device is authenticated using a federation-based network. In some embodiments, the access provider contacts an identity provider to authenticate the client device. At block <NUM>, a request to create a UDN is received, and at block <NUM>, the client device is added to the UDN. In some embodiments, the identify provider receives the request, creates the UDN, and adds the client device to the UDN.

At block <NUM>, a list of one or more UDNs associated with the identifier of the client device is updated. In some embodiments, the identity provider updates the list and forwards the list to the access provider. At block <NUM>, the access provider creates a local instance of the UDN using the MAC address of the client device and the unique identifier of the client device.

At block <NUM>, the user of the client device sends an invitation for the UDN to a second client device. At block <NUM>, the second client device is authenticated into the UDN using the identity provider (or another identity provider). The identity provider may update the list of UDNs associated with the second client device. At block <NUM>, the access provider receives the updated list of UDNs associated with the second client device. At block <NUM>, the access provider determines whether two or more client devices (here, the first client device and the second client device) are included in the same UDN. At block <NUM>, the access provider creates a local instance of the UDN when the two or more client devices are included in the UDN. The method <NUM> ends following completion of block <NUM>.

<FIG> is a method <NUM> of automated grouping of client devices for a UDN, according to one or more embodiments. The method <NUM> may be used in conjunction with other embodiments, e.g., performed using the access provider <NUM> of <FIG>.

The method <NUM> begins at block <NUM>, where the access provider advertises support for the federation-based network. At block <NUM>, the access provider advertises support for the automatic grouping of client devices for UDNs. In some embodiments, the advertising of block <NUM> and <NUM> is responsive to a query from a client device, such as an ANQP query.

At block <NUM>, the access provider requests a list of one or more UDNs that are associated with the client device. In some embodiments, the access provider requests the list responsive to the client device being authenticated by an identity provider. In some embodiments, the access provider transmits a unique identifier of the client device to the UDN network (UDN cloud).

At block <NUM>, the access provider determines, using the list of UDN(s), whether any other client device that is currently on the access provider network belongs to a same UDN. At block <NUM>, responsive to determining that two or more client devices list the same UDN, the access provider creates the local instance of the UDN. At block <NUM>, the access provider joins the two or more client devices to the UDN. The method <NUM> ends following completion of block <NUM>.

<FIG> and <FIG> illustrate a sequence of joining a client device to a UDN, according to one or more embodiments. The features illustrated in diagrams <NUM>, <NUM> may be used in conjunction with other embodiments. For example, the diagrams <NUM>, <NUM> may represent one or more blocks of the method <NUM> of <FIG>.

As discussed above, the access provider <NUM> represents networking hardware that is located in proximity to the client device <NUM> and provides wireless connectivity for the client device <NUM>. In some embodiments, the networking hardware of the access provider <NUM> is owned or operated by a venue. The diagrams <NUM>, <NUM> further comprises cloud-based infrastructure <NUM> that represents networking hardware that may be located remotely from the client device <NUM> and/or the access provider <NUM>.

The access provider <NUM> comprises an access point (AP) <NUM>, a wireless LAN controller (WLC) <NUM>, a policy engine <NUM>, and a software-defined network (SDN) controller <NUM>. In some embodiments, the AP <NUM> provides access to the client device <NUM>, the WLC <NUM> joins the client device <NUM> and orchestrates authentication, the policy engine <NUM> provides dynamic user (or the client device <NUM>) to group mapping and policy definition, and the SDN controller <NUM> provides centralized management and control, automation, and policy enforcement across physical and virtual network environments.

The cloud-based infrastructure <NUM> comprises a user-defined network (UDN) cloud <NUM>, a federation-based network <NUM>, and the identity provider <NUM>. Generally, the UDN cloud <NUM> represents the cloud-based devices that manage the propagation of UDN information from the identity provider <NUM> (e.g., maintained lists of UDNs in which the client devices are included) to the access provider <NUM> (e.g., which groups the client devices into local instances of UDN(s) based on the received lists).

In one exemplary sequence, the client device <NUM> detects advertising by the access provider <NUM> that indicates support for automatic grouping of client devices into UDNs. The client device <NUM> transmits an authentication request that includes a unique identifier of the client device. In the diagram <NUM>, the unique identifier is transmitted to the UDN cloud <NUM> via the AP <NUM>, the WLC <NUM>, the policy engine <NUM>, and the SDN controller <NUM>. In this way, the access provider <NUM> can map the current MAC address of the client device to the UDN grouping without transmitting the MAC address to the federation-based network or the identity provider <NUM>.

In the diagram <NUM>, the authentication request of the client device <NUM> is transmitted to the identity provider <NUM> via the AP <NUM>, the WLC <NUM>, the SDN controller <NUM>, and the federation-based network <NUM>. When the identity provider <NUM> confirms the authentication request, the user is authenticated without creating a UDN.

The UDN cloud <NUM> may send a list of UDNs associated with the unique identifier to the access provider <NUM>. The WLC <NUM>, the policy engine <NUM>, and the SDN controller <NUM> may join the client device <NUM> to the local instance of the UDN if the list indicates that the client device <NUM> belongs to the UDN listed by another device also associated on the network.

In an alternate implementation, the access provider <NUM> may create a UDN for every device, even for cases where no other devices from the same UDN are present. Beneficially, creating the UDN allows undesired traffic (e.g., P2P traffic) to be blocked, while any desired traffic (e.g., mDNS or broadcast traffic) is added by the access provider <NUM> as a shared resource. In this way, creating the UDNs provides a granularity for attaching policies. For example, the policies may be applied per-user and not per-device, which tends to simplify the workflow.

In the current disclosure, reference is made to various embodiments. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Additionally, when elements of the embodiments are described in the form of "at least one of A and B," it will be understood that embodiments including element A exclusively, including element B exclusively, and including element A and B are each contemplated. Furthermore, although some embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the aspects, features, embodiments and advantages disclosed herein are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to "the invention" shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

Claim 1:
A method (<NUM>) of automated grouping of client devices for a user-defined network, UDN, the method comprising, at an access provider (<NUM>, <NUM>):
receiving (<NUM>), from a first client device (<NUM>, <NUM>), an authentication request to join an access provider network, wherein the authentication request includes a unique identifier (<NUM>) of the first client device for a federation-based network (<NUM>);
transmitting the unique identifier to a UDN cloud (<NUM>);
transmitting (<NUM>) the authentication request to an identity provider (<NUM>, <NUM>);
receiving (<NUM>), responsive to the identity provider authenticating the authentication request, a list of one or more UDNs, from the UDN cloud, that are associated with the unique identifier; and
joining (<NUM>), using the list of one or more UDNs, the first client device with one or more other client devices present on the access provider network listing a same UDN in which the first client device is included.