MXPA06009887A - Mobility enabled system architecture software architecture and application programing interface - Google Patents

Abstract

The present invention is related to the software architecture and supporting application programming interface (API) that enable operating system (OS) independence and platform independence of a mobility enabled system architecture (MESA) in a wireless local area network (WLAN). The present invention provides a system for supporting portable and modular software implementation in different platforms in a WLAN node. The node includes a control plane configured to implement a control plane algorithm while interacting with a medium access control (MAC) driver, a data plane configured to implement a data plane algorithm while interacting with the MAC driver and, an operation, administration and maintenance (OAM) handler task configured to interact with the OAM agent. APIs are provided to enable interaction with external modules regardless of the differences of OS, specificity of OAM agent implementation and AP platform differences.

Description

ARCHITECTURE OF SYSTEM ARCHITECTURE SOFTWARE ENABLED OF MOBILITY AND INTERCONNECTION OF PROGRAMMING APPLICATION FIELD OF THE INVENTION The present invention relates to a wireless communication system. More particularly, the present invention relates to a software architecture and a support application programming interconnection (API) that enables the independence of the operating system (OS) and the platform independence of an architecture of the mobility-enabled system (MESA). ) in a wireless local area network (WLAN).

BACKGROUND As an example, a WLAN is typically based on an architecture where the system is subdivided into cells where each cell is referred to as a basic service set (BSS). Each cell is typically controlled by an access point (AP). The communication between the AP and the stations (STA) is defined, for example, by the 802.11 standard. Although the WLAN can be conformed by a single cell, with a. Single AP, most WLANs comprise several cells where the AP is connected through a main structure, called distribution system (DS), typically Ethernet. The entire interconnected WLAN that includes the different cells, their respective APs and the DS is typically considered as a single 802.11 network and can be referred to as an extended service set (ESS).

BRIEF DESCRIPTION OF THE INVENTION The present invention relates to software architecture and API support that allows the independence of OS and platform independence of a MESA in a WLAN. The present invention provides a system for supporting portable and modular software implementation in different platforms in a WLAN node. The node includes a control plane configured to implement a control plane algorithm and interact with a media access control (MAC) driver, a data plane configured to implement a data plane algorithm and interact with the driver. MAC and a task management and maintenance (OAM) operation configured to interact with the OAM agent. The APIs "are provided to allow interaction with external modules regardless of OS differences, OAM agent implementation specificity, and differences in the AP platform." The control plane includes a channel quality control task and the plane data includes the data entry task and the data output task.The channel quality control task collects measurements from the MAC controller and coordinates with other tasks.Data entry tasks and output task data transfer data to and from the MAC impeller.

BRIEF DESCRIPTION OF THE DRAWINGS A more detailed understanding of the invention can be obtained from the following description of a preferred embodiment, provided by way of example and to be understood in conjunction with the accompanying drawing, in which: Figures IA and IB are a high-level functional block diagram of a MESA software architecture in accordance with the present invention; Figure 2 is a block diagram of a MESA software task level architecture; Figure 3 is a block diagram of a MESA software architecture control plane versus a view of a data plane; Figure 4 is an example of integration of the MESA software architecture in a commercial AP, according to the present invention; Figures 5A and 5B are a signaling diagram of a start-up procedure according to the present invention; and Figures 6 and 7 are block diagrams showing an application programming interconnection between MESA software and an external environment, according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES Below, the terminology "STA" includes, but is not limited to a wireless transmitter / receiver unit, a user equipment, a mobile station, a fixed or mobile subscriber unit, a pager or any other type of device capable of operating in a wireless environment. Additionally, all of these terms may be used interchangeably where each of the terms includes, but is not limited to all other terms. When referring to the following, the AP terminology "includes, but is not limited to, a base station, a Node B, a site controller or any other type of interconnection device in a wireless environment. they can be used interchangeably where each of the terms includes, but is not limited to, all other terms MESA's focus is on the development of radio resource management (RRM), service quality (QOS) ) and the algorithms related to mobility management in the WLAN nodes such as routers, APs and STAs The drawing figures used to describe the present invention are mainly based on AP.However, it should be noted that the same architecture also can be implemented in other WLAN nodes, such as a WLAN router or WLAN stations (ie mobile terminals) .The AP has been used to illustrate the architecture of MESA software because the fat AP architecture option which concentrates most of the WLAN intelligence in the AP seems to be the predominant AP solution in the WLAN market today. AP portable radio frequency communication, user authentication, communication coding, secure roaming, WLAN management and in some cases network routing. Algorithm intelligence resides in the station management entity (SME). The interconnection of algorithms with the medium access control layer (MAC) management entity (MLME) and the physical layer management entity (PLME) through the service access point interconnects (SAP) . In general, a MESA software architecture in accordance with the present invention allows a software implementation that is modular and easily portable to different user platforms with minimal cost and development time. The inclusion of an API layer within the MESA software architecture separates the MESA algorithms from the peculiarities of platforms and OS of future clients. This greatly simplifies the integration of MESA software as an intermediary between the various client platforms. Referring now to the figures, Figure 1 is a high-level functional block diagram of a system 100 that includes the MESA software architecture in accordance with the present invention. System 100 includes a station that coordinates with other tasks for collection measurement and performs the relevant filtering, as required. The task 252 ChannelQualCtrl also handles the association request messages from the MAC 220 impeller and collects acknowledgment messages (ACK) sent to the neighboring APs during a silent measurement period (SMP). An SMP is a period during which the PA does not transmit any data but only listens to its environment in order to collect measurements used by the MESA algorithms. Task 252 ChannelQualCtrl implements algorithms such as frequency selection algorithms, energy detection threshold algorithms and power control algorithms. The logical segment for the generation of audible packets is implemented in task 256 Data_Out. The algorithms implemented in task 252 ChannelQualCtrl can be requested based on periodic timers of predefined measurement threshold activators. Task 252 ChannelQualCtrl shares the control of the startup phase with task 258 OAM_Handler and handles OAM requests such as enabling / disabling RRM features. The QOS algorithms are distributed between task 252 ChannelQualCtrl and task 256 Data_Out. Task 256 Data_Out transfers data to the MAC controller 220 and collects statistics related to the transmitted data, such as bad frames accounts, good frames accounts, own AP channel utilization, lost ACK number, and so on. Task 256 Data_Out implements the speed control and the programming algorithms and some part of the QoS algorithms. In support of power control algorithms, task 256 Data_Out calculates a received signal strength indicator (RSSI) for the associated STAs using RSSI measurements collected by task 256 Data_Out and updates histograms used by an interference calculation procedure slow control of power. Task 256 Data_Out also updates the last instance of its own AP load histogram by adding the duration of the - - Tx packets within the relevant path loss bin maintained by task 252 ChannelQualCtrl. Task 254 Data_In receives information requested by the MESA algorithms in the data entering from the 220 MAC impeller and transmits this information to a RRM software. The RRM software maintains a row for each STA associated with the AP. The OAM_Handler task 258 interacts with the 240 OAM agent to obtain and distribute configuration parameters to other MESA tasks, process various operations and failure management statistics collected by other MESA tasks, and filter these statistics as required for reporting purposes to an OAM administrator (not shown) via agent 240 OAM. The OAM_Handler task 258 also reports the ready status of the MESA software (as received from task 252 ChannelQualCtrl) to agent 240 OAM. The MESA software architecture according to the present invention uses a distributed database approach to minimize immobilization / release requirements and the related negative impact on the operation of the system. The databases are classified into two categories: a local database such as databases 262, 264 and a shared database 270 ..

There is at least one local database per task. The local databases include the following sub-databases (secondary databases): specific configuration parameters for each task; measurement data and algorithm-specific internal data. The configuration parameters come from a MIB and are distributed by task 258 OAM_Handler which obtains them from a 240 OAM people. Algorithm-specific internal data need to be maintained in a specific database for that algorithm. This includes the filtering outputs made in a measurement database. The local database for the OAM_Handler tasks 258 can include the operation and the statistical data that is obtained for presentation to the OAM administrator. The shared database 270 includes data that may be required to be shared by more than one task. The shared database 270 also includes configuration parameters that need to be shared among various tasks, measurement data that needs to be used for more than one task, and algorithm outputs that need to be observed by other tasks. Figure 3 is a diagram of a system 300 wherein the MESA software architecture 302 includes a data plane 310 and a control plane 320 according to the -. - present invention. In accordance with the present invention, a control plane 310 is separated from the data plane 320 by providing flexibility in setting data handling priorities (i.e., data output versus data entry). The modular architecture of the present invention provides easy future scalability and enables activation of the feature separately from each other. The portable condition can be obtained by a well defined interconnection to external modules such as an 802.11 chip set impeller 304, an OAM 306 and OS agent (not shown). All tasks are carried out concurrently allowing the measurements to be processed in the background while the data is transferred at the same time. The data plane algorithms determine the optimal data rate, the protocol transmission rows and implement part of the congestion control and admission control (ie, QoS) algorithms. The control plane algorithms implement frequency management, power control algorithms and part of the related QoS algorithms. As an example, the following is an explanation of the tasks performed during a startup phase. In the start-up phase, task 350 ChannelQualCtrl operates in an initialization state (Init state) and a Discovery_SMP state. In the Init state, the task - 352 ChannelQualCtrl obtains the initial OAM configuration parameters and performs one or several software initialization procedures. In the Discovery_SMP state; the SMP activities are carried out. At the end of the Discovery_SMP state, task 352 ChannelQualCtrl points to task 356 Data_Out and remains in the same state. Once the task 352 ChannelQualCtrl receives an indication of the task 356 Data_Out indicating the end of the packet generation procedure aloud, the task 352 ChannelQualCtrl performs the initial power calculation Tx. The task 352 ChannelQualCtrl then indicates to the other tasks (that is, the tasks Data_0ut 356, Data_In 354 and OAM__Handler 358) the end of the start phase, sets all the timers for a normal operation phase, establishes the relevant measurements and transits to the NormalOp_Main state. In the start-up phase, Task 356 Data__Out operates in the Init state and the Discovery_LPG state. In the Init state, task 356 Data_0ut obtains the initial OAM configuration parameters and performs software initialization procedures. In the Discovery_LPG state, task 356 Data_0ut executes the boot phase of the packet generation procedure in a loud voice. At the end of the procedure, Task 356 Data_Out points to task 352 ChannelQualCtrl to indicate the end of the packet generation procedure in a loud voice and remains in the same state. In the start-up phase, task 254 Data_In obtains the parameters of the initial OAM configuration, OAM and performs the software initialization procedures. Task 354 Data_In performs transitions from the Init state to the NormalOp_Main state upon receipt of the message indicating the end of the boot phase from task 352 ChannelQualCtrl. In the start-up phase, task 358 OAM_Handler operates in the Init state. In this state, task 358 OAM_Handler obtains the initial parameters of the OAM configuration and performs software initialization procedures. Task 358 OAM_Handler also distributes OAM parameters to other MESA tasks. After each start-up phase, the MESA software enters a normal operating phase. The possible states of task 352 ChannelQualCtrl in normal operation phase are NormalOp_Main status, NormalOp_SMP status and ChannelUpdate status. In the NormalOp_Main state, task 352 ChannelQualCtrl obtains measurements and various statistics on data received from the associated STAs, filters the measurements, periodically calculates the use of the current channel of the AP and executes MESA algorithms. In. NormalOp_SMP status, task 352 ChannelQualCtrl performs measurements of neighboring APs such as channel utilization, RSSI in the presence of a carrier insurance for all channels in ACS that includes the channels that are currently being used by AP, RSSI in absence of a carrier insurance (interference measurement), the number of ACKs sent by STAs to neighboring APs. The filtering of the measurements always takes place in the background regardless of the state. Task 356 Data_Out or task 354 Data_In does not need to be known in the NormalOP_SMP state of task 352 ChannelQualCtrl. The timer used to store the ACK / NACK reception by the 356 Data_Out task for data transmitted to the associated STAs will be set to a value greater than the SMP duration in normal operation phase. During the channel update, task 352 ChannelQualCtrl transitions to the ChannelUpdate state. The states of task 356 Data_Out in a normal operation phase are a NormalOp_Main state and a WaitForAck state. In the NormalOp_Main state, task 356 Data_0ut transfers data to the MAC driver, updates the slow interference evaluation statistics (that is, the prediction of RSSIs and perceived STAs), and other statistics that pertain to the activity definitions of the task- 356 Data Out. RSSI measurements perceived by AP are collected by task 352 ChannelQualCtrl and stored in a measurement database. The Tx power level change indication is also transferred by the 356 Data_Out task to the MAC driver upon notification from the 352 ChannelQualCtrl task. In a WaitForAck state, the Task 356 Data_Out waits for ACK / NACK. Assuming that ACK and NACK are followed by MAC and that the NACK timer resides on the MAC, there is no need to explicitly track the timer that stores the packet transmission duration loudly (for example T) with a separate timer. However, with this scenario, an internal variable is preferably provided for tracking whether the timer (T) can be reset or not upon receipt of ACK / NACK. In the normal operation phase, task 354 Data_In operates in the NormalOp_Main state. In this state, task 354 Data_In performs the normal data transfer activities between task 354 Data_In and task 356 Data_Out. In the normal operation phase, task 358 OAM_Handler operates in the NormalOp_Main state. In this state, task 358 OAM_Handler routes the addition and parameters of updated requests to other MESA software tasks, operation processes and fault management requests from the OAM agents and filtering, as required. Figure 4 is an example of integration of the MESA software architecture in a commercial AP according to the present invention. The MESA software product branded as "Performware" by Interdigital Communications Corporation is integrated into the Atheros AP platform. In this example, the APIs are divided into three (3) categories: the OS API 402 (OS layer); the OAM 404 APIs and the MAC 406, 408 MAC / Hardware Control (HWC) / Hardware Abstraction Layer (HAL) APIs. The OS API 402 provides generic functions which are used by the MESA software to access the OS services. These functions implement the details of each operating system in such a way that the MESA software algorithms are not aware of the differences between the underlying OSs supported. Each target platform may have different OAM agents with different implementations and interconnections of network management protocol. The OAM API 404 isolates the MESA software from these differences by handling the specificity of each OAM agent implementation. The API 406, 408 MAC / HWC / HAL provide the MESA software with uniform access, regardless of the differences in the AP platform for the MAC resources and the physical layer for the purpose of controlling the parameters of AP operation, ie , frequency, power level, etc.), the associated stations as well as the measurements required by the MESA algorithms. With reference to Figure 5, the activities performed during the MESA software start-up procedure are explained in sequence. After the AP is turned on, the OEM vendor software invokes the main boot function of the MESA software. In the boot function, following OS services belonging to the MESA software are initialized: memory management services and buffer memory; communication channels (between the MESA tasks and the environment and between different tasks); timer services and synchronization services. The identifiers of the channels are stored in a global structure to facilitate communication between different tasks. After initializing the aforementioned services, the boot function results in different application tasks. In the Init state, all tasks perform software initialization (step 502). The OAM agent sends an OAM start request to the OAM__Handler task (step 504). The OAM_Handler task sends the request to the - - task ChannelQualCtrl (step 506). All the algorithm data are sent to the Data_Out task except the speed control and the protocol setter (RCS) and part 1 of the detected energy threshold (EDT), which is sent to the Data_In task (steps 508, 510). The ChannelQualCtrl task, the Data_Out task, and the Data_In task populate the OAM database (step 512). The Data_Out task and the Data_In task send an OAM start confirmation to the OAM_Handler task (steps 514, 516). The ChannelQualCtrl task enters a Discovery_SMP state (step 518) and performs SMP activities (step 520). The task ChannelQualCtrl calculates the initial base interval in step 522 and executes the initial frequency selection (step 524). The task ChannelQualCtrl then sends a packet generation request aloud (LPG) to the Data_Out task in step 256. The LPG request is discovered in step 528 and the Data_Out task generates packets out loud in step 530 and the confirm to the ChannelQualCtrl task (step 532). Upon receipt of the confirmation, the task ChannelQualCtrl calculates the initial power Tx and initializes the normal operation (steps 534, 536). The task ChannelQualCtrl sends an indication for the start of normal operation to the Data_0ut task and the Data_In task (steps 542, 548, respectively) and sends a start confirmation of. OAM to the OAM Handler task (step 538) which sends the confirmation to the OAM agent (step 540). Then, the Data_In task, the Data_Out task, the ChannelQualCtrl task, and the OAM_Handler task go into normal operation (steps 552, 546, 550, and 544, respectively). An API mechanism in accordance with the present invention is explained with reference to Figures 6 and 7. In accordance with the present invention, a unique interconnection to / from an OEM vendor software (i.e., with the functions send_to_mesa (send to table) and send_from_mesa (send from table)) and a function of Dispatch_Buffer, which is internally called by the functions send_to_mesa or send_from_mesa are provided to transfer the message to the appropriate receiving task. It is noted that although a single interconnection is provided, the implementation of interconnection can be changed as needed. Figure 16 shows an API mechanism for communication from an external environment to a MESA software. A MESA functional block 602 requests a 604 send_from_MESA function to transfer a message to a 608N, 608N + 1 receiver task. The 604 send_from_MESA function generates a message 605 comprising a message header 605a and message parameters 605b and requests function 606 Dispatch_Buffer. The call can be a functional call or a message to a message row of a router system. The 606 Dispatch_Buffer function places the message 605 in the receiver task message row based on the message header 605a. The tasks continually monitor their row in search of a new message and then call their internal API processing function when one is detected. Figure 7 shows an API mechanism for communication from the MESA software to an external environment. A MAC block 702 or OAM functional requests function 704 send_to_MESA to transfer a message to a receiver task 708 ?, 708N and 708N + 1. The function 704 send_to_MESA generates a message 705 comprising a message header 705a and message parameters 705b and requests the function 706 Dispatch_Buffer. The 706 DispatchJBuffer function places the message 705 in the receiver task message row based on the message header 705a. This scheme provides a clean separation between the MESA software and the vendor software and uses POSIX message rows, one per receiver task. The rows of receiver tasks preferably belong to the shared memory domain that is controlled by an OS kernel. This scheme requires two system flames, one to establish the message in the receiver's row and another to retrieve the message from the receiver's row. The - system call (especially on the receiver side) can cause a receiver task to be reprogrammed. The buffer that is transmitted may not be large (for example of some objects). In a data plane, as described in connection with Figure 3, the actual user data is provided with a reference and not copied. Some of the MESA features can be implemented directly in the context of vendor software if required by the vendor. In this case, the 706 Dipatch_Buffer function can directly request the receiving function that processes the specific API. However, this requires a detailed knowledge of the software architecture of the vendor with an additional effort of adapting the front end. The advantage of this solution is that it provides an improvement in operation especially for algorithms implemented in the data path. The data plane algorithms can benefit from this. Although the elements of the figures are illustrated as separate elements, these elements can be implemented in a single integrated circuit (IC) such as a specific integrated circuit for application (ASIC), multiple ICs, separate components or a combination of separate components and one or several IC. Although the features and elements of the present invention have been described in the preferred embodiments in particular combinations, each feature or element can be used only without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the invention. the present invention. In addition, the present invention can be implemented in any type of wireless communication system.

Claims (22)

- - CLAIMS

1. System to support implementation of portable and modular software on different platforms in a wireless local area network (WLAN) node, the node includes a higher layer entity, a medium access control (MAC) impeller, an operating agent, administration and maintenance (OAM) and a physical layer entity, the system comprises: a control plane configured to implement a control plane algorithm while interacting with the MAC impeller; a data plane configured to implement a data plane algorithm while interacting with the MAC driver; an OAM handler task configured to interact with an OAM agent; and an application programming interconnection (API) that enables interaction with external modules regardless of the specificity and implementations of the external modules. System as described in claim 1, wherein the control plane includes a channel quality control task and the data plane includes a data entry task and a data output task, the task of Channel quality control collects measurements from the MAC impeller and coordinates with other tasks, the incoming data task and the output data task, the data transfer to and from the MAC impeller. A system as described in claim 2, wherein the channel quality control task handles association request messages from a MAC driver and collects recognition messages (ACK) from the neighboring APs during a silent measurement period. System as described in claim 2, wherein the channel quality control task implements frequency selection algorithms, energy detection threshold algorithms and power control algorithms. System as described in claim 4, wherein the channel quality control task implements the algorithms periodically. System as described in claim 4, wherein the channel quality control task implements the algorithms according to preferred threshold activators. System as described in claim 1, wherein a radio resource management (RRM) API is implemented in the MAC impeller to collect measurements and statistics and update a MAC and a physical layer entity with the output of the RRM . 8. System as described in claim 1, wherein at least one-OEM function "which is provided by OEM vendors is included in the node, and the OEM vendor API is implemented in the MAC driver. System as described in claim 8, wherein the MESA functional block is provided to transfer a message between the OEM function and an appropriate MESA task. 10. System as described in claim 9, wherein an issuing function is requested by the MESA functional block to transfer the message to the appropriate task, according to the message header. 11. System as described in. Claim 10, wherein the issuing function is requested either by a functional call or by a message to the message row of the router system. System as described in claim 9, wherein a row of the MESA task belongs to a shared memory domain that is controlled by the core of an operating system (OS). System as described in claim 10, wherein at least one MESA task is implemented in the OEM function. System as described in claim 13, wherein the function directly requests an appropriate function that processes the API. System as described in claim 1, wherein a connection system RRM and an abstraction API of the operating system (OS) is implemented in the MAC impeller. 16. System as described in claim 15, wherein the RRM connection and the OS abstraction API includes the memory allocation APIs, the buffer management APIs and the timer service APIs. System as described in claim 1, wherein the RRM API for OAM is implemented in the OAM agent for both the registration and access of the standard management information base (MIB). 18. System as described in claim 1, wherein the node is one of an access point (AP), a WLAN router and a terminal station. System as described in claim 2, wherein each task is provided with a local database and a shared database is provided to store data to which it will be accessed by all tasks. 20. System as described in claim 19, wherein the local database includes specific configuration parameters for each task, measurement data and algorithm-specific internal data. System as described in claim 19, wherein the shared database includes configuration parameters, measurement data and algorithm output that need to be shared among the various tasks. 2

2. System as described in claim 2, wherein all tasks run concurrently.