KR20090028668A - Procedure for handling successive diagnostic requests in wireless network - Google Patents

Abstract

A procedure for handling successive diagnostic request frames in a wireless network is provided to adaptively handle the successive diagnostic request frames according to whether a transmission station of a diagnostic request frame is the same station or another station. The second diagnostic request frame is received before diagnostic report about the received first diagnostic request frame is completed. When transmission stations of the second diagnostic request frame and the first diagnostic request frame are identical, the diagnostic report frame is generated/transmitted only about the second diagnostic request frame(S11,S12). Otherwise, a diagnostic report frame is generated/transmitted about both the first diagnostic request frame and the second diagnostic request frame(S13).

Description

Procedure for handling successive diagnostic request frames in wireless network

The present invention relates to wireless network management, and more particularly, to a processing procedure for a continuous diagnostic request in a wireless network.

Recently, with the development of information and communication technology, various wireless communication technologies have been developed. Wireless Local Access Network (WLAN) is based on radio frequency technology and uses portable terminals such as personal digital assistants (PDAs), laptop computers, and portable multimedia players (PMPs). It is a technology that enables wireless high-speed Internet access in certain service provision areas such as homes, businesses, or aircraft.

Since the establishment of Institute of Electrical and Electronics Engineers (IEEE) 802, a standardization body for LANs and Metropolitan Area Networks (MANs) including wireless LANs, was established in February 1980, a number of standardization work has been carried out. Since early WLAN technology supports speeds of 1 to 2 Mbps through frequency hopping, spread spectrum, infrared communication, etc. using 2.4 GHz frequency through IEEE 802.11, orthogonal frequency division multiplex (OFDM) recently. Up to 54Mbps can be supported by applying. In addition, IEEE 802.11 improves quality of service (QoS), access point (AP) protocol compatibility, security enhancement, wireless network management, and radio resource measurement. ), Wireless Access in Vehicular Environment, Fast Roaming, Mesh Network, Inter-working with External Network, Wireless Network Management The standard of various technologies such as Network Management is being put into practice or being developed.

Among these, wireless network management provides a protocol related to a procedure of collecting information on a wireless network, diagnosing a problem, or providing a service in a station (Station, STA) or an access point (AP). Event Request and Report, Diagnostic Request and Report, Presence Service, Basic Service Set (BSS) Transition Management (FBMS), Flexible Broadcast Multicast Service ), A traffic filter service (TFS), a sleep mode request and response, and the like.

Among them, the diagnostic request and the diagnostic report are intended to diagnose a complex network issue and to provide a means of debugging when a problem occurs. For example, an AP or STA that collects information about a network or attempts to solve a problem transmits a diagnosis request frame by specifying a predetermined diagnosis type to a station or a neighboring station subscribed to the AP or STA. As the type of diagnostic request, manufacturer information, operating parameters, capability, configuration profile, and the like are currently defined. Upon receiving the diagnostic request frame, the STA collects or measures necessary information according to the request content and transmits the result to the diagnostic report frame unless the diagnostic fails or the diagnostic service does not support the diagnostic service. However, in some cases, the reporting STA may receive another diagnosis request frame before completing the diagnosis report for the already received diagnosis request frame. As described above, when the STA continuously receives the diagnostic request frame, it becomes a problem how the reporting STA processes the continuous diagnostic request frame.

In the case of continuously receiving the diagnostic request frame, the STA cannot always process all the diagnostic request frames due to a time limit or a physical limit, or a user's right to use the STA. For example, if the first STA with a bad intention continues to transmit a new diagnostic request frame to the second STA and also receives a continuous diagnostic request frame, the STA must always process a new diagnostic request frame. Cannot process a diagnostic request from a third STA that is another STA. However, in order to prevent such a problem, the second STA cannot afford to perform internal processing necessary for itself while continuously processing a new diagnostic request in order to process all received consecutive diagnostic request frames.

Accordingly, an object of the present invention is to process all requests from several STAs when receiving continuous diagnostic request frames and to prevent unnecessary resources from being consumed in processing the diagnostic request frames. It is to provide a management procedure of a wireless network.

According to an aspect of the present invention, there is provided a method of processing a continuous diagnostic request frame in a wireless network, the method including receiving a second diagnostic request frame before completing a diagnostic report for the received first diagnostic request frame. When the transmitting stations of the first diagnosis request frame and the second diagnosis request frame are identical, a diagnosis report frame is generated and transmitted only for the second diagnosis request frame, and the first diagnosis request frame and the second diagnosis request frame are transmitted. If the transmission station of the frame is different, it includes generating and transmitting a diagnostic report frame for both the first diagnostic request frame and the second diagnostic request frame.

The processing procedure for the continuous diagnostic request frame according to another embodiment of the present invention for achieving the above technical problem is to receive a second diagnostic request frame before completing the diagnostic report for the received first diagnostic request frame, The processing of the received diagnostic request frame is adaptively performed according to whether the transmitting station of the first diagnostic request frame and the second diagnostic request frame is the same.

According to an embodiment of the present invention, when receiving a continuous diagnostic request frame, by varying the processing procedure according to whether the transmitting STA of the diagnostic request frame is the same or different STA, adaptive processing for the continuous diagnostic request frame Is possible. According to the embodiment of the present invention, even when a STA having a bad intention continuously transmits a diagnostic request frame, it is possible to process diagnostic requests from other STAs. In addition, when continuously receiving a diagnostic request frame from the same STA, by processing only the most recent diagnostic request frame, it is possible to process in accordance with the intention of the requesting STA.

Before describing an embodiment of the present invention, an architecture of a wireless network system to which an embodiment of the present invention can be applied will be described schematically.

The wireless network system may include, for example, at least one basic service set (BSS). The BSS refers to a set of successfully synchronized stations (STAs), which does not mean that the membership of the BSS is capable of wireless communication with all other STAs in the same BSS. The STA included in the BSS may be a terminal having mobility or may be a terminal fixed at a predetermined position.

Communication in the wireless network is performed in a Basic Service Area (BSA), which is an area including members belonging to a BSS. The boundary is somewhat unclear because the BSA may vary depending on the propagation characteristics of the wireless medium. These BSSs can be basically classified into two categories: independent BSS (IBS) and infrastructure BSS (infrastructure-structured BSS). The former forms a self-contained network. The BSS refers to a BSS that does not allow access to a distribution system (DS). The latter includes one or more access points and a distributed system. Generally, the access point includes an access point in all communication processes including communication between STAs. AP) is used.

The STA is a non-AP station as any functional medium including a medium access control (MAC) conforming to the IEEE 802.11 standard and a physical layer interface to a wireless medium. STAs belonging to a user may be referred to by other names, such as a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), or a mobile subscriber unit (Mobile Subscriber Unit). Can also be called. The AP is a functional entity that provides access to the DS via a wireless medium for an associated station (STA) connected to the AP. Since the AP has an STA function, when simply referred to as an STA in the present specification, the AP may be interpreted to include an AP except when it is not applicable in nature. The AP may be referred to as a centralized controller, a base station (BS), a node-B, or a site controller in addition to an access point.

Multiple BSSs may generally be interconnected through a distributed system. A plurality of BSSs connected to each other through a distributed system is called an extended service set (ESS). STAs included in the same ESS may communicate with each other, and within the same ESS, STAs may continuously communicate while moving from one BSS to another BSS, which is called a BSS transition.

For the purpose of wireless network management, STAs periodically or necessarily exchange a diagnostic request frame and a diagnostic report frame. For example, an AP trying to collect information of another STA or diagnosing a problem of another STA may transmit a diagnostic request frame to one or more STAs. The STA receiving the diagnostic request frame may transmit a diagnostic report frame including the requested information to the requesting AP. The diagnostic request frame and the diagnostic report frame are transmitted in a unicast manner, and if the target address of the diagnostic request / report frame is a multicast address or a broadcast address, the frame is discarded.

1 is a block diagram illustrating an example of a structure of a diagnostic request frame in a wireless network that may be used in an embodiment of the present invention. The diagnostic request frame is transmitted by a non-AP STA or an AP that wants to manage a wireless network or needs various information about the STA, and requests the STA that receives the diagnostic request frame to execute a diagnostic test or Ask for some information.

Referring to FIG. 1, the diagnostic request frame 100 includes a category field (Category, 110), an action field (Action, 120), a dialog token field (Dialog Token, 130), and a diagnostic request element field (Diagnostic Request Elements) field. It includes. The category field 110 is set to a value indicating a wireless network management category and may have a size of one octet. The action field 120 is set to a value indicating that the frame is a diagnostic request frame and may have a size of one octet. The dialog token field 130 may be set to a value selected by the STA transmitting the diagnostic request frame 100 to identify a transaction of the diagnostic request frame and the diagnostic report frame, and may have a size of one octet. . And the diagnostic request element field 140 includes one or more diagnostic request elements, the size of which is variable. The diagnostic request element includes a request for a station receiving a diagnostic request frame to perform a specific diagnostic action. The size of the diagnostic request element 140 is limited within the size of the maximum allowable Medium Access Control (MAC) Management Protocol Data Unit (MMPDU), and the number thereof is also limited within the size, but may be a plurality.

1, the diagnostic request element 140 includes an element ID subfield (Element ID) 141, a length subfield (Length, 142), a diagnostic token subfield (Diagnostic Token) 143, and a diagnostic request type sub. Field (Diagnostic Request Type, 144), and Diagnostic Information Sub-elements (145). The element ID subfield 141 is set to a value indicating a diagnostic request among various information elements. The length subfield 142 may have various values according to the length of the diagnostic information subelement subfield 145. The diagnostic token subfield 143 is set to a unique value among the diagnostic request elements of the diagnostic request elements sent to each destination MAC address that have not received the corresponding diagnostic report element. The diagnostic request type field 144 is set to a value for identifying the type of diagnostic request.

The diagnostic information subelement subfield 145 may include zero or more diagnostic information subelements according to a specific diagnostic request type. Diagnostic request element field when the diagnostic request type is a Manufacturer Information STA Report, an Operating Parameters STA Report, an STA Capability STA Report, or a Configuration Profile. 140 may not include the diagnostic information subelement subfield 145. In this case, however, the diagnostic report frame may include information about the diagnostic information subelement contents according to a preset or promised rule.

1, the diagnostic information subelement subfield 145 includes a diagnostic information sub-element ID unit 145a, a length unit 145b, and a diagnostic information subelement content unit. (Diagnostic Information Sub-element Contents, 145c). The diagnostic information subelement ID field 145a is set to a value indicating the type of diagnostic information subelement. The type of diagnostic information subelement includes, for example, an antenna type, an antenna gain, a result code, data rates, and the like. The length field 145b is set to a value indicating the length of the diagnostic information subelement content unit 145c. Diagnostic information subelement content field 145c includes diagnostic information subelement content.

Among the types of diagnostic information subelements, the result code can be used to give other indications about the diagnostic request frame that has already been sent. For example, if a diagnostic request frame has been previously transmitted but has not yet received a diagnostic report frame from the reporting STA, and also attempts to cancel the request, the diagnostic code is set to information indicating 'cancel' in the result code. You can send the frame again. An example of the value assigned to the result code is shown in Table 1.

2 is a block diagram illustrating an example of a structure of a diagnostic report frame in a wireless network that can be used in an embodiment of the present invention. The diagnostic report frame is sent by the station in response to the diagnostic request frame.

Referring to FIG. 2, the diagnostic report frame 200 includes a category field (Category, 210), an action field (Action, 220), a dialog token field (Dialog Token, 230), and a diagnostic report element field (Diagnostic Report Elements, 240). ). The category field 210 is set to a value indicating a wireless network management category and may have a size of one octet. The action field 220 may be set to a value indicating that the frame is a diagnostic report frame and may have a size of one octet. The dialog token field 230 may be set to a value corresponding to the received diagnostic request frame 100 and may have a size of one octet. The diagnostic report element field 240 includes one or more diagnostic report elements. The size and number of diagnostic report element fields 240 in the diagnostic report frame 200 are limited within the allowable MMPDU size.

2, the diagnostic report element field 240 includes an element ID subfield (Element ID 241), a length subfield (Length, 242), a diagnostic token subfield (Diagnostic Token) 243, and a diagnostic report type. It may include a subfield (Diagnostic Report Type, 244), a diagnostic status subfield (Diagnostic Status, 245), and a diagnostic information sub-elements (246). The element ID subfield 241 is set to a value indicating a diagnostic report element among values indicating various information elements. The length subfield 242 may have various values according to the length of the diagnostic information subelement field 246. The diagnostic token subfield 243 is set to the diagnostic token 143 of the diagnostic request element of the received diagnostic request frame 100. The diagnostic report type subfield 244 is set to a value for identifying the type of diagnostic report.

The diagnostic status subfield 245 may be set to a value indicating an overall result for the diagnostic request specified by the dialog token field 130 of the diagnostic request frame 100, that is, the value illustrated in the result code. Can be. For example, when the reporting STA can complete the diagnostic request included in the diagnostic request element of the received diagnostic request frame, the diagnostic status subfield 245 is set to a value indicating 'successful'. do. If the reporting STA is unable to process the received request, the diagnostic status subfield 245 is set to a value indicating 'failure'. In addition, when the STA that receives the diagnostic request frame does not support the diagnostic service, the diagnostic status subfield 245 is set to a value indicating 'Incapable'. In addition, the diagnostic information subelement subfield 246 includes a diagnosis result for the received diagnostic request frame 100, and one or more information subelements are sequentially included for each diagnostic report type. An example result code that may be used in the diagnostic status subfield 246 is shown in Table 2 below.

2, the diagnostic information subelement subfield 246 includes a diagnostic information sub-element ID unit 246a, a length unit 246b, and a diagnostic information sub-element content unit. Information Sub0element contents, 246c). The diagnostic information subelement ID unit 246a is set to a value indicating the type of the diagnostic information subelement. The length unit 246b is set to a value indicating the length of the diagnostic information subelement content unit 246c. And diagnostic information subelement content unit 246c includes diagnostic information subelement content.

3 is a flowchart illustrating a processing procedure when a continuous diagnostic request frame is received. Here, the 'continuous diagnosis request frame' refers to the 'first diagnosis request frame' that has already been received and the 'second diagnosis request frame' received before completing the diagnosis report for the first diagnosis request frame. Such a continuous diagnostic request frame is not necessarily limited to two, but also includes more than two frames. The diagnostic request frame may be, for example, a frame having the format shown in FIG. 1.

Referring to FIG. 3, a STA that receives a continuous diagnostic request frame determines whether a transmitting STA of a first received diagnostic request frame is identical to a transmitting STA of a later received second diagnostic request frame (S11). ). In the present embodiment, it is determined whether the transmitting STA is the same, but according to the embodiment, it may be determined whether the source STA is the same as the source STA. As a result of the determination, if the transmitting STAs are the same, the process proceeds to step S12, and if otherwise, the process proceeds to step S13.

In step S12, that is, when the transmitting STAs of consecutive diagnostic request frames are the same, the receiving STA processes only the most recently received frame, eg, the second diagnostic request frame. In this case, if the receiving STA was performing an operation for the first diagnostic request frame, the performing operation is stopped. As a result, the receiving STA generates a diagnostic report frame for the second diagnostic request frame and transmits it to the transmitting STA. In this case, the diagnostic report frame may include the same dialog token as the dialog token included in the second diagnostic request frame, indicating that the diagnostic report frame is a response to the second diagnostic request frame. The diagnostic report frame may be, for example, a frame having the format shown in FIG. 2.

On the other hand, in step S13, that is, when the transmitting STAs of consecutive diagnostic request frames are different, the receiving STA processes all the received frames, for example, the first and second diagnostic request frames. In this case, the receiving STA may process the successive diagnostic request frames sequentially, but in some cases, the receiving STA may first process the diagnostic request frame having priority. As a result, the receiving STA generates first and second diagnostic report frames for each of the first and second diagnostic request frames, and transmits them to the transmitting STA. The first and second diagnostic report frames may be, for example, frames having the format shown in FIG. 2.

In this case, the first diagnostic report frame includes the same dialog token as the dialog token included in the first diagnostic request frame, and the second diagnostic report frame includes the same dialog token as the dialog token included in the second diagnostic report frame. By including the token, it is possible to indicate that each diagnostic report frame is a response to a certain diagnostic request frame. Of course, as described above, when there is a lot of data to be transmitted for one diagnostic request frame, a plurality of diagnostic report frames including the same diallock token may be transmitted.

As described above, according to the embodiment of the present invention, when the continuous diagnostic request frame is received, the processing procedure is changed according to whether the transmitting STA of the diagnostic request frame is the same STA or a different STA. Adaptive processing is possible. In addition, even when a STA having a bad intention continuously transmits a diagnostic request frame, the STA may process diagnostic requests from other STAs. In addition, when continuously receiving a diagnostic request frame from the same STA, by processing only the most recent diagnostic request frame, it is possible to process in accordance with the intention of the requesting STA.

On the other hand, according to the above-described embodiment of the present invention, two result codes are used. One is illustrated in Table 1, and contains information such as the forced termination or the set timeout period for the already transmitted diagnostic request frame. The other is illustrated in Table 2, and contains information on the processing result for the received diagnostic request frame, such as success, failure, inability, and the like. However, using a result code of the same name for different purposes, that is, defining two similar code formats and using them in one procedure has a disadvantage of causing confusion in message processing. In addition, since the above-described result code does not indicate a specific reason for each piece of information, network management information is not sufficient.

One way to solve this problem is to combine the two result codes described above into one. 4 is a diagram illustrating an example of a result code generated according to an embodiment of the present invention. 4, in the embodiment of the present invention, all the information set in Table 1 and Table 2 are included in one result code. Therefore, using the result code according to the embodiment of the present invention, it is possible to use the same reason code in the diagnostic request frame or the diagnostic report frame.

Another way to solve this problem is to combine the two result codes described above into one and set different result codes depending on the reason for each case. 5 is a view showing another example of a result code made according to another embodiment of the present invention. Referring to FIG. 5, in another embodiment of the present invention, not only all the information set in Table 1 and Table 2 are included in one result code, but also different result codes are assigned to each information according to the reason. It can be seen that.

As mentioned above, although preferred embodiment of this invention was described in detail, if it is a person with ordinary knowledge in the technical field to which this invention belongs, this invention may be carried out without deviating from the mind and range of this invention contained in a claim. It will be appreciated that various modifications or changes can be made.

1 is a block diagram illustrating an example of a structure of a diagnostic request frame in a wireless network that may be used in an embodiment of the present invention.

2 is a block diagram illustrating an example of a structure of a diagnostic report frame in a wireless network that may be used in an embodiment of the present invention.

3 is a flowchart illustrating a processing procedure for a continuous diagnostic request frame according to an embodiment of the present invention in a wireless network.

4 is a diagram illustrating an example of a result code that may be used in a diagnostic request frame and a diagnostic report frame in a wireless network.

5 is a diagram illustrating another example of a result code that may be used in a diagnostic request frame and a diagnostic report frame in a wireless network.

Claims (2)

Receive a second diagnostic request frame before completing a diagnostic report for the received first diagnostic request frame, When the transmitting stations of the first diagnosis request frame and the second diagnosis request frame are identical, a diagnosis report frame is generated and transmitted only for the second diagnosis request frame, and the first diagnosis request frame and the second diagnosis request frame are transmitted. And generating and transmitting a diagnostic report frame for both the first diagnostic request frame and the second diagnostic request frame when the transmitting stations of the different stations are different. Receive a second diagnostic request frame before completing a diagnostic report for the received first diagnostic request frame, And processing the received diagnostic request frame adaptively according to whether the transmitting station of the first diagnostic request frame and the second diagnostic request frame is the same.

Images