CN116491169A

CN116491169A - Implementing service level agreements in identity federation

Info

Publication number: CN116491169A
Application number: CN202180074270.5A
Authority: CN
Inventors: 马尔科姆·M·史密斯; 杰罗姆·亨利; 马克·格雷森; 罗伯特·E·巴顿; 巴特·A·布林克曼
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2020-10-29
Filing date: 2021-10-26
Publication date: 2023-07-25
Also published as: EP4238334A1; US20220141714A1; US11627498B2; US20230300680A1; WO2022094550A1

Abstract

Embodiments of the present disclosure describe techniques for dynamically negotiating SLAs between a roaming device and a VN in the identity federation. IDP does not have to negotiate separately with a VN before the user device roams to the VN to decide on an SLA, but parties may dynamically negotiate an SLA after the user device detects a VN (but before the device is allowed to attach or associate with the VN). In one embodiment, when the roaming user device comes within wireless range of the VN, the roaming device receives an announcement from the VN indicating the current SLA(s) provided by the VN. The roaming device may compare this offered SLA with the SLA stored in the identity profile received by the device from the IDP to determine whether to accept the offer. In another embodiment, instead, the SLA is negotiated between the VN and IDP.

Description

Implementing service level agreements in identity federation

Cross Reference to Related Applications

The present application claims the benefit of co-pending U.S. patent application Ser. No. 17/148,146, filed on day 2021, 1, and month 29, which claims the benefit of U.S. provisional patent application Ser. No. 63/107,130, filed on day 2020. The above-mentioned related patent applications are incorporated by reference in their entirety into the present application.

Technical Field

Embodiments presented in the present disclosure relate generally to dynamically achieving a Service Level Agreement (SLA) for a roaming device in an identity federation.

Background

Open roaming (or, more generally, identity federation) allows roaming devices to use a single ID for authentication and joining a Visited Network (VN) (also referred to as an access network) operated by different entities. These federates include identity providers (IDPs) that establish trust relationships with VNs. When a user device (e.g., a cell phone, notebook, tablet, etc.) roams to a VN, the VN may utilize its trust relationship with the IDP to authenticate the device.

For example, it is often cheaper for a cellular provider to switch a user device from its cellular network to a Wi-Fi network (e.g. VN) belonging to the same identity federation, even though the cellular provider has to pay for the bandwidth used by the user device to the Wi-Fi network. However, a cellular provider (e.g., IDP) may wish to ensure that the user receives the lowest level of service (e.g., minimum bandwidth or maximum latency) when connecting to a VN. This requires the cellular provider to negotiate with Wi-Fi network providers in the identity federation to guarantee a certain SLA for its customers. Considering that the identity federation may have hundreds of different VNs and that VNs are added continuously, it is difficult (if not impossible) to negotiate with each VN in the identity federation.

Drawings

So that the manner in which the above recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate typical embodiments and are therefore not to be considered limiting; other equally effective embodiments are also envisaged.

FIG. 1 illustrates a system for negotiating SLAs in an identity federation according to one embodiment described herein.

Fig. 2 is a flow chart of a user device negotiating an SLA with a VN according to one embodiment described herein.

FIG. 3 illustrates a system for negotiating SLAs in an identity federation according to one embodiment described herein.

Fig. 4 is a flow chart of IDP negotiating SLAs with a VN according to one embodiment described herein.

FIG. 5 is a flow chart for monitoring compliance with a negotiated SLA according to one embodiment described herein.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.

Detailed Description

SUMMARY

One embodiment presented in this disclosure is a method comprising: selecting a first Service Level Agreement (SLA) standard provided by an identity provider (IDP) for a user equipment; and receiving, at the user device, an announcement from a Visited Network (VN) indicating an SLA supported by the VN, wherein the announcement is received before the user device is associated with the VN, and wherein the IDP and the VN are part of the same identity federation. In the case where it is determined that the SLA supported by the VN meets the first SLA criterion, the method includes: transfer accept from the user device to the VN and associate the user device with the VN.

Another embodiment described in this disclosure includes a non-transitory computer readable medium having program instructions embodied therein, the program instructions executable by a processor to perform operations. These operations include: selecting a first SLA criterion provided by the IDP for the user equipment; and receiving, at the user device, an announcement from the VN indicating the SLAs supported by the VN, wherein the announcement is received before the user device is associated with the VN, and wherein the IDP and the VN are part of the same identity federation. In the event that it is determined that the SLA supported by the VN meets the first SLA criterion, the operations include: transfer accept from the user device to the VN and associate the user device with the VN.

Another embodiment described in this disclosure is a method comprising: it is determined that the user device is attempting to attach to the VN, wherein the user device was previously supplied by the IDP, and wherein the IDP and the VN are part of the same identity federation. The method further comprises the steps of: negotiating an SLA for the user device between the IDP and the VN before the user device attaches to the VN; and allowing the user device to attach to the VN after the VN has authenticated the user device with the IDP and has agreed on the SLA.

Example embodiment

Embodiments of the present disclosure describe techniques for dynamically negotiating SLAs between a roaming device and a VN in the identity federation. IDP does not have to negotiate individually with each VN to decide on an SLA before the user device roams between VNs, but in the embodiments described below, parties may dynamically negotiate an SLA after the user device detects a VN (but before the device is allowed to attach or associate with a VN). In one embodiment, when the roaming user device comes within wireless range of the VN, the roaming device receives an announcement from the VN indicating the current SLA(s) provided by the VN. The roaming device may compare this offered SLA with the SLA stored in the identity profile (profile) received by the device from the IDP. If the offered SLA matches (or exceeds) the requirements in the stored SLA, the device transmits an acceptance to the VN, which then allows the device to attach (assuming the device has been properly authenticated by the IDP).

In another embodiment, rather than the roaming device accepting an SLA, the VN and IDP negotiate an SLA for the roaming device as part of the authentication process when the roaming device attempts to connect to the VN. In one example, the IDP communicates the offered SLA to the VN, which then decides whether it can meet the SLA. If not, the VN denies the offer. Alternatively, the VN may transmit a reverse proposal (counter) to the IDP, which may decide whether to accept the reverse proposal, even if this is not ideal. The IDP may not make a decision but push the terms of the reverse proposal to the roaming device so that the user can decide whether to accept the SLA. Alternatively, the user may want to try to use a different IDP (which may obtain more favorable terms from the VN than the current IDP) or to connect to a different VN also in wireless range to determine whether the VN provides a better SLA.

FIG. 1 illustrates a system 100 for negotiating SLAs in an identity federation according to one embodiment described herein. System 100 includes an open roaming federation 115 that establishes trust between IDP 120 and VN 150 so that roaming device 135 can be authenticated using credentials stored in IDP 120. However, embodiments of the present disclosure may be applied to any identity federation where trust is established between a VN and IDP 120 so that roaming device 135 may be identified. In general, the open roaming federation 115 allows the VN 150 to authenticate the roaming device 135 so that the device 135 can attach to the VN 150. Furthermore, embodiments of the present disclosure utilize the open roaming federation 115 to also enable the VN 150 to negotiate SLAs for the roaming device 135.

Roaming device 135 has a service agreement with at least one IDP 120. For example, IDP 120 may be a cellular service provider, cloud computing service, social media platform, etc., that allows roaming devices 135 to connect to VNs 150 in open roaming federation 115 using a single ID. As part of registering with IDP 120, the user may be guaranteed a particular SLA when joining VN 150. For example, the SLA may provide minimal bandwidth, reduced latency, high priority handling of guaranteed specific applications (e.g., video conferencing applications, gaming applications, voice over IP (VoIP) applications, etc.), minimal performance during peak hours, and so forth. A user may negotiate an SLA with IDP 120 or may be assigned an SLA as a benefit of registering with IDP 120.

In fig. 1, roaming device 135 receives identity profile 160 from IDP 120. In addition to identity profile 160 including credentials (e.g., device ID) that nomadic device 135 can use to authenticate to VN 150 when attached, identity profile 160 also includes SLA requirements 165 that describe the SLA that device 135 guarantees when device 135 is connected to VN 150. As discussed in more detail below, the roaming device 135 may compare the SLA requirements 165 with the SLA notification 170 provided by the VN 150. If the SLA advertised by VN 150 does not meet SLA requirements 165 in its identity profile 160, roaming device 135 may decide not to attach to VN 150.

In this example, VN 150 includes an SLA monitor 155 that can evaluate performance metrics corresponding to VN 150 to determine what type of SLA it can support. For example, the SLA monitor 155 may determine the minimum bandwidth or maximum delay that the VN 150 may provide to the roaming device 135. The SLA monitor 155 may also determine whether the VN 150 may prioritize certain applications or provide special treatment to the roaming device 135 during peak hours. Some of these metrics may vary depending on the current load on the VN and its state. For example, if the VN 150 is currently lightly loaded (e.g., relatively few devices connected to the VN 15), the VN 150 may be able to provide higher bandwidth and lower latency. However, other metrics may be static (and may be set by a system administrator), such as whether the VN 150 provides priority for certain applications regardless of the current load on the VN 150. The SLA monitor 155 can then use the metrics to generate an SLA advertisement 170 for the nomadic device 135.

Currently, open roaming uses the Access Network Query Protocol (ANQP) to allow roaming devices 135 and VN 150 to advertise services provided by Access Points (APs) in VN 150. The agreement (as defined in IEEE 802.11 u) may be modified to also include an SLA notification 170 indicating the SLA type(s) supported by VN 150. However, embodiments of the present disclosure are not limited to utilizing ANQP (or updated versions of ANQP) to communicate SLA notification 170, but may use any communication protocol that facilitates communication between VN 150 and roaming device 135 prior to attachment of roaming device 135 to VN 150.

VN connector 140, coupled to VN 150, interoperates with IDP connector 125, IDP connector 125 being associated with home network 130. These connectors 140, 125 provide means for dynamic discovery of peers, dynamic establishment of secure tunnels, and carrying identity and authentication packets, which do not require prior knowledge nor pre-established peer-to-peer protocols between IDP 120 and VN 150. Each VN 150 may have an associated VN connector(s) 140 (e.g. one for Wi-Fi, one for LoRa, one for PLTE, one for 5G, etc., or they may all be integrated into a single entity).

The various components in fig. 1 may be implemented using software, hardware, and combinations thereof. For example, IDP 120 may include one or more computing systems having software that performs the functions described in this disclosure. IDP connector 125 and VN connector 140 may be software modules running on respective computing systems. Further, home network 130 and VN network 150 may include a plurality of network devices, such as APs, routers, switches, controllers, and the like. Roaming device 135 may be any wireless user device (e.g., tablet, smart phone, laptop, etc.) that includes a processor and memory.

Fig. 2 is a flow chart of a method 200 for a roaming device (e.g., user device) to negotiate an SLA with a VN in accordance with one embodiment described herein. At block 205, the user selects an SLA requirement when the roaming device is provisioned by an IDP. That is, as part of provisioning (or providing registration) by the IDP to the roaming device, the user may select an SLA or one or more individual SLA criteria as desired. In one embodiment, the selection includes selecting individual SLA parameters, such as minimum bandwidth, upload speed, download speed, maximum latency, higher priority of the gaming application, and so forth. In another embodiment, the IDP provides a predefined SLA from which the user may select. For example, the IDP may provide a gold, silver, copper plan, where the SLA of the gold plan requires a better quality of service than the silver plan, which in turn provides a better quality of service than the copper plan. In one embodiment, the user subscribes to the IDP and pays for the guarantees provided in the SLA requirements. However, in another example, the IDP may provide the SLA as part of a free service.

When the roaming device attaches to a network operated by the IDP (e.g., home network 130 in fig. 1), the IDP may ensure that the quality of service meeting the selected SLA requirements is provided to the roaming device. However, when roaming devices roam to different networks (e.g., VN network 150 in fig. 1) that are not operated by the IDP, the IDP (and the user) may still need those same SLA requirements. The method 200 provides the user with the technique of receiving the same SLA when connecting to a VN as when connecting to the home network.

At block 210, the roaming device receives an identity profile from the IDP, including the SLA requirements selected at block 205. For example, the SLA requirements may list various performance indicators that the VN should provide to the roaming device. The identity profile may also include information required by the VN to authenticate the roaming device in the identity federation such as open roaming.

At block 215, the roaming device receives an SLA notification from the VN while roaming. The SLA notification indicates that the VN may provide an SLA for the roaming device. For example, the SLA may indicate whether the minimum bandwidth (e.g., minimum upload/download speed) guaranteed by the VN, whether it provides a higher priority for certain applications (e.g., teleconferencing, gaming, voIP, etc.), and so on. In one embodiment, an SLA monitor in a VN generates an SLA notification by monitoring performance metrics of the VN, such as current network traffic, number of connected devices, throughput, etc. Thus, the SLAs provided to the roaming device may vary depending on the current values of these performance indicators. Alternatively, the SLA provided by the VN may vary with time of day. For example, if the roaming device attempts to connect to a VN during peak hours as opposed to off-peak hours, the VN may advertise a lower performing SLA. In yet another example, the SLAs provided in the SLA notification are fixed and not altered unless altered by a system administrator.

In another embodiment, the VN may advertise the SLA after identifying the IDP corresponding to the roaming device. The VN may announce a "default" SLA to the roaming device at block 215, but then, upon starting to find the IDP, the VN may unicast back a customized (or adjusted) SLA to the roaming device in response to identifying the IDP for the roaming device. For example, a VN may advertise a better SLA to roaming devices according to its IDP. The roaming device may then accept/reject the SLA, as described below.

At block 220, the roaming device determines whether the advertised SLA meets the SLA requirements stored in its identity profile. For example, if the SLA requirements in the identity profile specify a minimum bandwidth, the roaming device determines whether the advertised SLA guarantees that the bandwidth is equal to or higher than the minimum bandwidth.

In one embodiment, the roaming device ensures that the advertised SLA meets all stored SLA requirements in the identity profile. In another embodiment, the roaming device may prioritize SLA requirements, where an advertised SLA only needs to meet higher priority requirements, or an advertised SLA only needs to meet a threshold number of SLA requirements (e.g., at least five SLA requirements). In another example, the advertised SLA may only need to be within the threshold of the SLA requirements. For example, if the advertised minimum bandwidth is at least 95% of the minimum bandwidth specified in its identity profile, the roaming device may determine that the advertised SLA still meets the SLA requirements. In other words, an advertised SLA may provide lower performance than a stored SLA requirement, but may still be acceptable as long as the advertised SLA is within the threshold of the stored SLA requirement.

Assuming the advertised SLA meets the SLA requirements, the method 200 proceeds to block 225 where the VN transmits an acceptance to the VN. The roaming device may then be associated with (or attached to) the VN after authentication by the identity federation at block 230. For example, prior to allowing the roaming device to attach to the VN, the VN uses the identity information received from the roaming device to authenticate the roaming device with its corresponding IDP. That is, the VN may authenticate the roaming device using a trust relationship with the IDP. Once authenticated, the VN allows the roaming device to attach and ensures that the service level of the roaming device meets the agreed SLA-i.e., the VN announces an SLA at block 215. In this way, the VN and the roaming device may dynamically agree on an SLA before the roaming device attaches to the VN.

If the roaming device determines that the advertised SLA does not meet the stored SLA requirements, the method 200 proceeds to block 235, where the roaming device may inform the user. For example, the nomadic device may display a Graphical User Interface (GUI) indicating that the VN does not meet its SLA with the IDP or output an audio message indicating that the VN does not meet its SLA with the IDP. The GUI or audio message may indicate the difference between the SLA advertised by the VN and the SLA requirements stored in the identity profile. The user may then have the following selections: the advertised SLA is known to provide poor performance but still agree to the advertised SLA, attempt to connect to a different VN that may provide a better SLA, or use a different communication network (e.g., cellular network instead of switching to Wi-Fi network).

FIG. 3 illustrates a system 300 for negotiating SLAs in an identity federation according to one embodiment described herein. System 300 has the same components as system 100 in fig. 1, such as IDP 120, open roaming federation 115, VN connector 140, home network 130, VN 150, and roaming device 135. Accordingly, these components are not described in detail herein. Unlike fig. 1, system 300 does not push SLA requirements 145 to roaming device 135. Here, instead of roaming device 135 determining whether to accept or reject the SLA advertised by VN 150, the negotiation takes place between IDP 120 and VN 150. As shown, SLA requirements 145 are stored in IDP 120. In one embodiment, VN 150 and IDP 125 communicate using RADIUS servers or routers, but this is merely an example of one suitable manner of communication.

Although roaming device 135 does not include SLA requirements 145, roaming device 135 may still have an identity profile (which is provided by IDP 120) that is shared with VN 150 so that VN 150 can authenticate roaming device 135 as part of open roaming federation 115.

Fig. 4 is a flow chart of a method 400 of negotiating an SLA with a VN by an IDP according to one embodiment described herein. At block 405, the user selects an SLA requirement when provisioning the roaming device with IDP. That is, as part of provisioning (or providing registration) with the IDP to the roaming device, the user may select the SLA that he wants. Similar to block 205 in method 200, the selection may include selecting individual SLA parameters, such as minimum bandwidth, upload speed, download speed, maximum latency, higher priority of the gaming application, and so forth. In another embodiment, the IDP provides a predefined SLA from which the user may select. For example, an IDP may provide a gold, silver, copper card plan. In addition, the user may pay for the IDP, or his service may be free. In one embodiment, method 400 provides a technique for a user to receive the same SLA when connected to a VN as when connected to the home network.

At block 410, the roaming device attempts to roam to (or attach to) a VN. In one embodiment, unlike method 200, the VN does not provide SLA notification to the roaming device. Alternatively, the VN may provide an SLA announcement to the roaming device, but the roaming device may ignore the announcement because it has no SLA requirements. In this case, the VN may support roaming devices that store SLA requirements in the identity profile as well as roaming devices that do not store SLA requirements.

As part of roaming, the device communicates identity information (e.g., device ID) to the VN using, for example, ANQP. The identity information may be stored in the roaming device identity profile.

At block 415, the VN authenticates the roaming device with the IDP using the device ID. This process may vary depending on the type of identity federation being implemented, but in any event, this process exploits trust between the VN and IDP to enable the VN to trust the roaming device as well. In one embodiment, the VN uses the identity information provided by the roaming device to identify the IDP that issued the identity information. The VN may then communicate the device ID to the IDP so that it can authenticate the roaming device.

At block 420, the VN receives SLA requirements from the IDP as part of (or in parallel with) the authentication process. In other words, the IDP may communicate SLA requirements for the roaming device to the VN before (or during) authentication of the roaming device by the IDP.

At block 425, the VN determines whether it can meet SLA requirements. For example, the SLA monitor may evaluate the current performance index of the VN, or the VN may compare the SLA requirements to its own predefined (or fixed) SLA.

If the VN is able to meet the SLA requirements, at block 430 the VN communicates acceptance to the IDP. At block 435, the VN allows the nomadic device to attach assuming that the nomadic device is properly authenticated. The VN then provides the roaming device with a service level that meets the SLA agreed with the IDP.

Returning to block 425, if the VN is unable to meet the SLA requirements provided by the IDP, the method 400 proceeds to block 440 where the VN proposes a reverse proposal to the IDP. For example, a VN may be able to meet the minimum download speed required by an IDP but not the minimum upload speed, or a VN may be able to meet the bandwidth requirement but not provide higher priority for teleconferencing applications. In reverse proposition, the VN may formulate which SLA requirements can be met and which requirements cannot be met. For example, the reverse proposal may indicate that the VN may meet the lowest download speed, but may ensure that the lowest upload speed is only 90% of the upload speed of the IDP request.

At block 445, the IDP determines whether to accept the reverse proposal. For example, the IDP may prioritize its SLA requirements so that if the VN is unable to meet the SLA requirements of lower priority, the IDP may still accept the reverse proposal. Alternatively, if the performance index in the SLA is within 10% of its requested value, the IDP may still accept the reverse proposal. If the IDP accepts the reverse proposal, the method 400 proceeds to block 435 where the VN allows the roaming device to attach (again assuming the roaming device is authenticated).

If the IDP does not accept the reverse proposal, method 400 proceeds to block 450 where the IDP informs the user through the roaming device. For example, the roaming device may display a GUI indicating the requested SLA requirements and SLAs provided by the VN. The user may then choose to accept the SLA, in which case the IDP may relay the acceptance to the VN, which then allows the roaming device to attach.

Alternatively, the user may have registered several different IDPs. For example, a user may wish to attempt to connect to a VN using a different IDP, which is desired to have a special relationship with the VN, and thus may negotiate a better SLA than the current IDP. For example, the IDP currently negotiated with the VN may be the cellular provider of the roaming device, which may not have any particular relationship with the VN. However, the user may also have an account for another IDP that provides cloud services. The user may use this identity profile to connect to the VN and then prompt the VN to negotiate with the new IDP. The IDP may have a special relation to the VN, so the VN may accept the SLA requested by the IDP.

In another example, the user may be aware that several other VNs are available (e.g., several wireless VNs in the same vicinity as the user). For example, a user may be in a mall where there are several Wi-Fi networks available that belong to the same identity federation. The user may decide to try a different VN to see if the IDP can negotiate a better SLA.

While method 400 describes IDP communicating its SLA requirements to the VN at block 420, in other embodiments, the VN communicates its SLA to the IDP instead. The IDP may then determine whether the proposed SLA meets the SLA requirements and if not, provide a reverse proposal to the VN, which the VN may accept or reject, as described in block 445.

Furthermore, although the method 400 describes the VN (or IDP) providing a reverse proposal, in another embodiment, the VN may simply reject or accept SLA requirements. That is, the VN may not provide a reverse proposal to the initial proposal provided by the IDP. If the VN refuses the initial proposal, the IDP may still inform the user so that the user may instruct the IDP to authenticate the device when required so that it may attach to the VN (without an agreed SLA), or the user may attempt to attach to the VN using a different IDP, or to try a different VN (if available).

In one embodiment, if the VN accepts the proposal (or the IDP accepts the reverse proposal), the VN allocates network resources in slices (slices) to ensure that the VN meets the SLA for the roaming device. Implementation of a sliced SLA may be achieved by first grouping users into a particular group within the SSID. The roaming device may be grouped into an IEEE 802.11ax Association ID (AID) list. This AID list forms a set of devices in the SSID to which the SLA is to be applied. However, this is just one example of how a VN may provide a roaming device with an agreed SLA.

Further, the service of SSID may use the following technique: priority scheduling mechanisms assigned to radio resources, including rescheduling Resource Units (RUs) to roaming devices, ensuring that quality of service (QoS) policies are applied to eligible clients in the SSID, limiting the number of clients that get an SLA on a particular radio in the AP at a particular point in time (if the roaming devices that get an SLA at a point in time are too many, resources may run out, all clients will not meet the SLA, and in this case the VN will reject SLA proposals), or ensuring priority radio access (e.g., IEEE 802.11v recommends roaming with the least congested radio around the client, recommends roaming at a higher RSSI/data rate level than other clients).

FIG. 5 is a flow chart of a method 500 for monitoring compliance with a negotiated SLA according to one embodiment described herein. The method 500 assumes that an SLA has been negotiated between the VN and the roaming device using either of the methods 200, 400 described in fig. 2 and 4. The method 500 provides a technique to ensure that the VN provides a level of service guaranteed by the SLA.

At block 505, the roaming device or VN may monitor compliance with the agreed SLA. For example, when attaching to a VN, the roaming device may determine whether the VN provides the minimum upload/download speed indicated in the SLA. On the other hand, VNs can monitor compliance with SLAs by activating telemetry monitoring for roaming devices and measuring how much bandwidth each roaming client allocates and how much bandwidth they consume. When an AP in a VN transmits download traffic to a roaming device, compliance may be measured at the AP to ensure that the roaming device is allocated a certain amount of bandwidth. Alternatively, in the upload direction, when checking the result of the Buffer Status Report (BSR) returned by the roaming device, if the bandwidth requested by the roaming device is being provided by the AP according to the SLA, a record is made. Furthermore, the SLA may follow the roaming device as it roams from AP to AP in the VN. In addition, bandwidth to the internet can be measured and guaranteed for each nomadic device. The internet gateway router may then participate in this because the VN ensures that bandwidth guarantees are provided for the roaming device (not only for WLAN bandwidth but also for internet oriented bandwidth).

Delay may also be measured for clients according to SLAs. Although the delay across the internet cannot be measured, the wireless controller or AP may measure the delay from the client to the internet gateway and between the gateway and a fixed point on the internet (e.g., a um rella DNS server, IDP application server, or others).

At block 510, the nomadic device or VN provides a report to the IDP regarding the compliance of the VN with the SLA. The report may include a minimum bandwidth or maximum delay measured by the nomadic device or VN over a period of time (e.g., ten minutes). In one embodiment, the roaming device or VN provides reports at predefined intervals.

In one embodiment, the roaming device or VN provides a report at the end of the device session. For example, a VN may use VN and IDP connectors to provide results of sessions (e.g., billing data), whether roaming devices are serviced according to SLAs, total bandwidth consumed, and amount of time on the network, etc.

At block 515, the IDP determines whether the SLA is satisfied by evaluating the report. In this example, the IDP pays a set fee to the VN depending on whether the VN provides a service level to the roaming device that meets the SLA. If the VN complies with the SLA, at block 520, the IDP decides to pay the set price to the VN. In addition, the IDP may then charge the user of the roaming device (assuming this is not part of the subscription to the IDP).

If the SLA is not complied with, then at block 520, the IDP requests the VN to offer a discount. This discount may vary depending on how different the actual performance is from the performance of the SLA guarantee. For example, if the actual download speed is 15% slower than the lowest download speed in the SLA, the IDP may require a 15% discount. If the actual download speed is 20% slower, the IDP may require a 20% drop, and so on. In this way, the IDP may pay for the use of the VN by the roaming device in a manner that accurately reflects the ability of the VN to adhere to the agreed SLA.

When the SLA can no longer be provided (e.g., the roaming device moves out of range), in one embodiment, the VN returns an SLA failure message to the IDP along with a reason code (e.g., KPI failure) and billing data for all monitored KPIs. The IDP may return a "continue" message if the fallback (fallback) profile SLA can still be guaranteed, otherwise return a "stop" message. The VN may also deliver this message to the user through the roaming device through protected ANQP messaging (for the device then should stop/continue and the VN forwards the device decision along with the charging data to the IDP).

The following examples are different techniques for applying SLAs to real-time and non-real-time traffic in a VN wireless network.

Real-time downlink traffic from groups (AID lists) in the SLA may be aggregated separately from other traffic (i.e. for Downlink (DL) OFDMA purposes) rather than grouped with other user equipment. The SLA parameters (e.g., delay) of the group are set to meet a minimum delay requirement (e.g., 20 milliseconds). Note that this requirement can also be met if the same aggregation parameter is valid for other devices (i.e. by globally adjusting the parameter). Before meeting the delay constraint, the AP may transmit a DL OFDMA MU PPDU with the required RU allocation to deliver the RT traffic (including other device traffic if RU space allows) for the slice.

Non-real-time DL traffic from the SLA group (AID list) may be aggregated separately from other traffic (i.e., for DL OFDMA purposes) rather than grouped with other devices. Although stringent timing requirements are not required, a minimum overall throughput constraint (e.g., 25 Mb/s) may be used, thus applying the same aggregation logic as described above (e.g., forming an OFDMA MU PPDU based on user devices in a group). To meet the minimum constraint, the VN allocates a minimum number of RUs for the group in each TXOP based on, for example, a leaky bucket approach (where minimum throughput is the token transmission interval).

Real-time upload traffic from the SLA group (AID list) may be distributed by: the scheduling group is first polled at a frequency compatible with the delay requirement (e.g., 20 ms) to determine the buffer status report BSR, and then UL OFDMA HE MUPPDU with sufficient RU is triggered from the BSR (then deducted from the token bucket).

Non-real-time upload traffic may be distributed by: the SLA group is first polled at a worst case frequency compatible with MSDU timeout requirements (e.g., 200 ms) to determine the BSR, and then UL OFDMA HE MUPPDU with sufficient RU is triggered from the BSR (then deducted from the token bucket).

In this disclosure, various embodiments are referenced. However, the scope of the present disclosure is not limited to the specifically described embodiments. Rather, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice the contemplated embodiments. Further, 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 only element a, only element B, and both elements a and B are considered, respectively. Moreover, although some embodiments of the disclosure may achieve advantages over other possible solutions or over the prior art, whether a given embodiment achieves a particular advantage does not limit the scope of the disclosure. Thus, the various aspects, features, embodiments, and advantages of the disclosure are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Similarly, references to "the invention" should not be construed as an generalization of any inventive subject matter of the present disclosure and should not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, embodiments of the present disclosure may be embodied as a system, method or computer program product. Thus, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, embodiments may take the form of a computer program product embodied in a computer-readable medium(s) having computer-readable program code embodied thereon.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer and as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagram illustrations of methods, apparatus (systems) and computer program products according to embodiments presented in the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block(s).

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart illustrations and/or block diagram block(s).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each block in the flowchart illustrations or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Disclosed herein are apparatuses and/or systems arranged to perform any of the methods described herein.

In view of the foregoing, the scope of the disclosure is determined by the appended claims.

Claims

1. A method, comprising:

selecting a first Service Level Agreement (SLA) standard provided by an identity provider (IDP) for a user equipment;

receiving, at the user device, an announcement from a Visited Network (VN) indicating SLAs supported by the VN, wherein the announcement is received before the user device is associated with the VN, and wherein the IDP and the VN are part of the same identity federation; and

transmitting an acceptance from the user device to the VN and associating the user device with the VN, in case it is determined that the SLA supported by the VN meets the first SLA criterion.

2. The method of claim 1, further comprising: the first SLA criterion is received at the user equipment from the IDP before transmitting the acceptance.

3. The method of claim 2, wherein the first SLA criteria is stored in an identity profile received from the IDP in the user device, the identity profile further comprising identity information for use by the VN to authenticate the user device with the IDP.

4. A method according to claim 3, wherein the user device is attached to the VN only after the VN has authenticated the user device with the IDP based on the identity information.

5. The method of any preceding claim, wherein the VN comprises a Wi-Fi network and the user device is a wireless device.

6. The method of any of the preceding claims, further comprising:

outputting at least one of a Graphical User Interface (GUI) or an audio message to a user of the user device, the GUI or audio message indicating a difference between the first SLA standard and the VN-supported SLA, in case it is determined that the VN-supported SLA does not meet the first SLA; and

after outputting the GUI or audio message, an input is received from the user regarding whether to agree to the SLA supported by the VN in order to attach the user device to the VN.

7. A non-transitory computer readable medium having program instructions embodied therein, the program instructions being executable by a processor to perform operations comprising:

selecting a first SLA criterion provided by the IDP for the user equipment;

receiving, at the user device, an announcement from a VN indicating SLAs supported by the VN, wherein the announcement is received before the user device is associated with the VN, and wherein the IDP and the VN are part of the same identity federation; and

8. The non-transitory computer-readable medium of claim 7, wherein the operations further comprise:

the first SLA criterion is received at the user equipment from the IDP before transmitting the acceptance.

9. The non-transitory computer-readable medium of claim 8, wherein the first SLA criteria is stored in an identity profile received in the user device from the IDP, the identity profile further comprising identity information for use by the VN to authenticate the user device with the IDP.

10. The non-transitory computer readable medium of claim 9, wherein the user device is attached to the VN only after the VN has authenticated the user device with the IDP based on the identity information.

11. The non-transitory computer-readable medium of any one of claims 7 to 10, wherein the operations further comprise:

in the event that it is determined that the VN-supported SLA does not meet the first SLA, outputting at least one of a Graphical User Interface (GUI) or an audio message to a user of the user device, the GUI or audio message indicating a difference between the first SLA standard and the VN-supported SLA.

12. The non-transitory computer-readable medium of claim 11, wherein the operations further comprise:

13. A method, comprising:

determining that a user device is attempting to attach to a VN, wherein the user device was previously supplied by an IDP, and wherein the IDP and the VN are part of the same identity federation;

negotiating an SLA for the user device between the IDP and the VN before the user device attaches to the VN;

after the VN has authenticated the user device with the IDP and has agreed the SLA, the user device is allowed to attach to the VN.

14. The method of claim 13, wherein negotiating the SLA for the user equipment comprises:

receiving, at the VN, a first SLA criterion transmitted by the IDP, wherein the first SLA criterion was previously selected by the user equipment when provisioned by the IDP; and

an indication is transmitted from the VN to the IDP indicating whether the VN is capable of meeting a plurality of requirements of the first SLA standard.

15. The method of claim 13 or 14, wherein negotiating the SLA for the user equipment comprises:

receiving, at the VN, a first SLA criterion transmitted by the IDP, wherein the first SLA criterion was previously selected by the user equipment at the time of provisioning by the IDP; and

upon determining that the VN is unable to meet a plurality of SLA requirements in the first SLA standard, a reverse proposal is transmitted from the VN to the IDP.

16. The method of claim 15, wherein negotiating the SLA for the user equipment comprises:

transmitting a modified SLA based on the reverse proposal from the IDP to the user device for user approval, wherein the modified SLA is different from the first SLA standard.

17. The method of any of claims 13 to 16, further comprising: the SLA is communicated to the user device for user approval prior to allowing the user device to attach to the VN.

18. The method of any of claims 13-17, wherein authenticating the user device with the IDP comprises:

receiving identity information from the user device at the VN, wherein the identity information indicates that the IDP is associated with the user device;

based on the identity information, the user device is authenticated by communication between the VN and the IDP.

19. The method of any of claims 13 to 18, wherein the VN comprises a Wi-Fi network and the user device is a wireless device.

20. The method of any of claims 13-19, wherein negotiating the SLA for the user equipment comprises:

transmitting a first SLA criterion from the VN to the IDP; and

an indication is received from the IDP as to whether the first SLA criterion meets a second SLA stored in the IDP, the second SLA being previously selected by the user equipment at the time of provisioning by the IDP.

21. A non-transitory computer readable medium having program instructions embodied therein, the program instructions being executable by a processor to cause performance of the method of any one of claims 13 to 20.

22. An apparatus arranged to perform the method of any one of claims 1 to 6 or 13 to 20.