- a. disable peer-to-peer applications;
- b. disable ad hoc-networking;
- c. enable VoIP applications;
- d. dis-allow routing/packets to go via this MU to enable mesh networking; and
- e. allow electronic mail (“email”) SMTP traffic and HTTP traffic only, etc.
  Those of skill in the art will understand that this is not a comprehensive list of network settings that can be activated by the Context, but rather a representative subset of possible settings that may be defined for this particular context.

In a second exemplary embodiment, a Conference Main-Context may also be defined. This context may include the following network settings:

- a. enable peer-to-peer applications;
- b. enable ad hoc networking;
- c. disable VoIP applications and personal soft/phone
- d. allow routing/packets to go via this MU to enable mesh networking;
- e. disable email traffic;

These two contexts may be configured at one or more of the MUs10-50 and at one or more of theAPs60 and70. As shown above, the contexts may be assigned a number in an index stored on the MUs10-50 and/or theAPs60 and70. For example, the Personal Workspace Main-Context may be assignedindex number1 which is the same on the MUs10-50 and/or theAPs60 and70. Thus, for example, if it is considered that the office of the user ofMU10 is in thecoverage area65 ofAP60, the user may select the above described Personal Work Space Main-Context when the user is in their office. Assuming that this context is configured at theMU10 and at theAP60, the appropriate network settings corresponding to the selected context will be set for theMU10 and theAP60. Therefore, the user of theMU10 will be provided with the desired service level on theMU10 when the user is in their office.

It may then be considered that the user moves to a different location, e.g., a conference room either in

coverage area

65 or75, to attend a meeting with other colleagues. At this point, the user may enable the Conference Main-Context to obtain the proper network settings for this situation. Again, this assumes that this context is configured at both theMU10 and thecorresponding AP60 and/or70. Thus, the user is providedMU10 with the desired service level on theMU10 when the user is in the conference room. This example shows that using contexts in accordance with the exemplary embodiments of the present invention, allows a user to dynamically change the service level the user is being provided on an MU based on either location and/or the situation.

As described above, the Main-Contexts may also include Sub-Contexts. The Sub-Contexts may be defined in the same manner described above for Main-Contexts. The Sub-Contexts would also be configured at the MUs and the APs which are configured for the corresponding Main-Context. Thus, the Sub-Contexts are additional selectable network settings that may be used to accomplish specific tasks within the defined Main-Context.

The above example of the Conference Main-Context will be continued to provide an example of a Sub-Context. For example, under the Conference Main-Context the user may have a choice of a plurality of defined Sub-Contexts. One exemplary Sub-Context may be a Projection Sub-Context. This Sub-Context may enable network settings on the APs and the MUs so that all the attendees of the conference to send data to, for example, a wireless-enabled device such as a projector for the data to be projected for the attendees to see the data.

To continue with the example, it may be considered that each of the users of

MUs

10,20 and30 were attendees and in the same conference room within thecoverage area65 of theAP60 and that the Conference Main-Context and Projection Sub-Context were configured at each of the

MUs

10,20 and30 and theAP60. Thus, when the users started the meeting, each of the users of

MUs

10,20 and30 may enable the Conference Main-Context and the Projection Sub-Context, thereby configuring the network settings of the

MUs

10,20 and30 and theAP60 to operate in accordance with the above description.

It may also be possible to configure the network such that only a single MU enables the Projection Sub-Context so that each attendees' data may be sent to the projector. In this example, an agent may reside on each MU that monitors the enabled contexts and activates the correct settings for the activation. For example, when a particular MU is enabled for the Conference Main-Context, the agent may monitor its associated AP to determine if the Projection Sub-Context has been enabled at the AP. If it is determined that the Projection Sub-Context has been enabled at the AP, e.g., by another attendee of the meeting, the agent will instruct the MU to set the appropriate network settings for the MU to operate in accordance with the projection Sub-Context.

Those of skill in the art will understand that the particular implementation of network settings needed to accomplish a specific task is not important to the exemplary embodiments of the present invention, but rather, that various contexts may be defined so that each user may dynamically enable these network settings to accomplish the tasks is the.

Continuing further with the example, it may also be considered that the users of the

MUs

40 and50 are in a conference room within thecoverage area75 of the AP70, but these users are also remote attendees of the same meeting. The Conference Main-Context and Projection Sub-Context may also be configured at each of the

MUs

40 and50 and the AP70. Thus, when the meeting started, each of the users of

MUs

40 and50 may enable the Conference Main-Context and the Projection Sub-Context, thereby configuring the network settings of the

MUs

40 and50 and the AP70 to also operate in accordance with the above description so that the remote attendees could also participate in the meeting.

Another example of a sub-context under the Conference Main-Context may be a Storage Sub-Context that enables network settings to provide that all meeting data/minutes may be stored to a network device such as, for example,network server80. A further example a sub-context under the Conference Main-Context may be a Sharing Sub-Context that may allow all attendees of the meeting who are operating under this Sub-Context to share files on their MUs without moving the files to the network, and activate a messaging/chat-room program allowing everyone to communicate. One of skill in the art will understand that there could be an infinite number of combinations of Main-Contexts and Sub-Contexts, and an infinite number of settings that may be applied by each context.

It should be noted that in the above example, each of the MUs that were associated with a particular AP were described with reference to all of the MUs enabling the same context and the MUs and AP having the same enabled network settings corresponding to the enabled context. However, it is also possible that different MUs that are associated with the same AP may have enabled different contexts. Thus, referring toFIG. 1,MU10 may enable a first context (e.g., an office context),MU20 may enable a second context (e.g., a meeting context) andMU30 may enable a third context (e.g., a presentation context), simultaneously. If theAP60 is configured for each of the three contexts, it may simultaneously handle the communications of each of these

MUs

10,20 and30 because the network settings may be associated with the particular connection for the particular MU. Thus, an AP is not limited to having a single context enabled at a time, it may enable multiple contexts according to the present invention.

In addition to default Main-Contexts and Sub-Contexts, the organization and/or the users may be able to custom-tailor Contexts. Users and/or organizations may be able to create their own custom Contexts, or alter the settings of existing Contexts. Moreover, if some specific functionality is required, a template may be provided to allow users to create a Context instantly and allow other users to access and utilize the newly created Context.

FIG. 2 shows amethod200 according to the exemplary embodiment of the present invention utilized to enable the use of main and sub contexts in a wireless network as the user changes their work environment. The method is described with reference toFIG. 1. Those skilled in the art will understand that other systems having varying configurations, and a multitude of Main-Contexts and Sub-Contexts may be used to execute the exemplary method.

Instep210, the user of an MU (e.g., MU20) is either deciding to connect to the wireless network in a specific work environment, or has moved their work environment while being connected to either

WLAN

100 or200. For example, the user may be coming into work in the morning, or moving from their personal workspace (e.g., cubicle, office, etc) to a conference room for a meeting.

Instep220, the user of theMU20 selects the proper Main-Context and Sub-Context for the new work environment. For example, the user of theMU20 may select a Conference Main-Context and a Projection Sub-Context that include the functionalities as described above. Deciding which context to select may be based on the network and service level settings desired by the user. Those of skill in the art will understand that the described examples of main and sub-contexts are merely exemplary, and there can be any number of main-contexts and sub-contexts depending on the preferences of the organization and/or user.

Instep230, the user of theMU20 applies and executes the appropriate Main-Context (and Sub-Context) on theMU20. This action may be performed by a software application specifically designed for the implementation of contexts. The software application may have all the settings stored for each of the configured contexts, and allow the user to select the main-context (and sub-context) from lists, pull-down menus, a database, etc.

Instep240, after the user has selected the appropriate main-context and sub-context via a software application, theMU20 then alerts theAP60 of this request. The information regarding the contexts may be transmitted within theMU20's probe request packet, re-association request packet, association request packet, a separate packet dedicated to the context setting of the MU, etc. Those of skill in the art will understand that the information regarding the contexts may be encrypted and stored in a plurality of formats and sent via any of a plurality of methods that allow the MU to communicate with the AP.

Instep250, theAP60 receives the data packets containing the information regarding the contexts that the user of theMU20 is selecting and theAP60 assesses whether to allow the user to connect with the requested main-contexts and sub-context. The algorithms used to either allow or deny access to a certain context may be specified by the organization. For example, the organization may have different classes of users with different authorization levels for certain contexts and levels of service.

Also, the exemplary embodiments of the present invention may be used as a security measure. If no context is specified in any of the packets transmitted by an MU, theAP60 may automatically designate the user as a Guest Context, and activate certain precautions such as limiting traffic, restricting access to some portions of the network, re-direct incoming traffic from the MU to a virus scan program, activate firewalls, etc.

Instep260, if it has been determined that theMU20 is authorized to use the requested contexts, the settings and level of service that have been stored for the requested main-context and sub-context will be applied for theMU20. There may exist default contexts that contain settings that have been preprogrammed. Moreover, the organization and/or user may be able to change the settings for default contexts, and add and create new contexts depending on the needs of the users and/or organization. These settings may include peer-to-peer networking settings, traffic based on VoIP, restricting of transmitted traffic, etc.

Instep260, once it has been verified by theAP60 thatMU20 is authorized to use the requested contexts, theAP60 would grant the MU20 a wireless connection that incorporates the settings associated with the contexts. This may include network settings of theMU20, and level of service settings of theAP60.

Instep270, there may be a case where the Main-Context and Sub-Context requested by the user of theMU20 are unacceptable according to the algorithms that have been predetermined by the organization. This may be because the user is not authorized to use the context, there may be a hard limit on the number of users utilizing the specific context, the particular AP is not configured for the requested context, etc. For example, because of Quality of Service (“QoS”) requirements, a particular AP may have a hard limit on the number of MUs that can associate with an AP and select a context that includes enablement of VoIP. Thus, even though a particular user may be authorized for a defined service level, the user may still be denied access to a context because other criteria not associated with the user may not be satisfied.

In this situation, the AP may suggest an alternative context to the user. The alternative context suggested by theAP60 may be selected based on an algorithm defined by the organization, or there may be a default context that is suggested when any user is denied use of a requested context. In the example provided above of a hard VoIP limit, the AP may suggest the closest context to requested context that does not include VoIP enablement.

Instep280, the user may decide whether or not the context suggested by theAP60 is acceptable. If the user finds the suggested context acceptable for the work environment, then the user will be connected to the wireless network with the suggested context applied (step260). However, if the user finds the suggested context unacceptable for the situation and rejects the suggested alternative, as shown instep290, theAP60 may disassociate theMU20 from the wireless network.

In addition, the AP may also monitor the MUs to determine their actual uses of resources in particular contexts. Based on this monitored usage, the AP may suggest or require a context switch on the part of an MU for the purpose of more efficiently using the network capabilities. To continue with the VoIP example started above, an MU may be operating using a context that has the VoIP enabled. However, the AP may determine that the MU has been operating for a defined period of time without using the VoIP capabilities. When a new MU requests a context that includes VoIP enablement, but the hard limit of VoIP users has been satisfied, the AP may send a request to original MU to determine if it can switch contexts in order to allow the new MU to be granted access to its desired context that includes VoIP enablement. This may be in the form of a request that may be accepted or declined by the original MU or in the form of a rule that requires the original MU to switch contexts. Other forms of context switching may also be based on priority levels for particular users, e.g., a higher priority user may be able to require that a lower priority user is context switched so that the higher priority user is granted access to its desired context.

In the above described examples, various functionality has been described for the MUs and the APs. Those of skill in the art will understand that this functionality may be implemented via hardware, software or a combination thereof on these devices. Where the functionality is implemented via software, this functionality may be included as part of separate software modules or as portions of one or more software applications implemented on the device.

It will be apparent to those skilled in the art that various modifications and variations can be made in the structure and the methodology of the present invention, without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.