Context management

0001(Citation of related application) This application applies to US Provisional Patent Application No. 61 / 837,845 (filed June 21, 2014), US Provisional Patent Application No. 61 / 844,689 (filed June 10, 2013), and US Provisional Patent Application No. 61 / 837,993. Claiming the interests of the issue (filed June 21, 2013), all disclosures of the above applications are incorporated herein by reference as if they were in their entirety.

0002Peer-to-peer (P2P) proximity communication can refer to infrastructure-based or infrastructureless communication between peers within close proximity to each other. Peers are, for example, mobile stations (MS) in 2G systems, or IEEE. 802.15 Can refer to a user or device, such as a full-featured device (FFD) or mitigation feature device (RFD) in a wireless personal area network (WPAN). Examples of P2P devices include connected cars, medical devices, smart meters, smartphones, tablets, laptops, game consoles, set-top boxes, cameras, printers, sensors, home gateways and the like. P2P proximity communication may focus on peers who are aware of their proximity to the desired service in infrastructure-based or infrastructureless configurations. For example, P2P communication can be implemented in a centralized system that includes a centralized controller, or in a fully distributed system that does not involve a central controller. In contrast to infrastructureless P2P communications, infrastructure-based communications often include, for example, centralized controllers for handling user information, scheduling between users, and managing connections (eg,). , Cellular communication). In infrastructureless P2P communication, peers typically have equal responsibility for initiating, maintaining, and terminating communication sessions. Proximity-based applications and services represent recent socio-technical trends. P2P proximity communications are used in various implementations, such as networks for social networks, advertising, emergencies, games, smart transport, and network scenarios.

0003In a typical social network implementation, close peers can interact with each other at the application level (eg Facebook, Twitter). Two-way communication between two or more peers is often required in the implementation of social networks for P2P proximity communication. Traffic data rates can be low (eg, text-based chat) or high (eg, content sharing). In an exemplary advertising implementation of P2P proximity communications, the store broadcasts its advertisements and coupons to potential customers (peers) within the proximity of the store's location. In this exemplary scenario, one-way communication with low data traffic is typical, but two-way communication can be used (eg, for personalized advertising).

0004Implementation of P2P proximity communication in emergencies usually involves one-way communication, such as an emergency alarm. Other emergency implementations require two-way communication, such as during emergency safety management scenarios. P2P emergency services / applications may have higher priorities than other P2P services / applications, and some emergency services / applications may have higher privacy requirements. In a P2P exemplary game console implementation, multiple peers initialize or participate in a two-way game (eg, an online multiplayer game that follows certain rules). Two-way P2P games often require low latency. In an exemplary smart transport implementation of P2P proximity communications, connected cars via car-to-car and / or car-to-infrastructure communications are bi-directional transports such as congestion / accident / event notifications, carpools and train scheduling. It can support advanced applications including management, smart traffic control, etc. Data rates in smart transport implementations are often low, but smart transport can require very reliable message delivery and very short latency. Network-to-network P2P can be used to extend the scope of the infrastructure and offload it from the infrastructure. Multi-hop can be a unique feature.

0005The aforementioned exemplary implementation of P2P communication may relate to Machine to Machine (M2M) and Internet of Things (IoT) applications. Existing approaches to proximity communication for M2M / IoT applications have performance issues. For example, contextual information is often managed in an isolated manner in which contextual information is not shared between different layers or peers.

<p num="0006"> Current approaches to managing contextual information such as location information, mobility information, device capabilities, user information, application categories, multi-hop information, channel status, application information, association identifiers, device information, etc. are capable of peer-to-peer (P2P) systems. Missing. For example, contextual information is often managed in an isolated fashion so that contextual information is not shared between different layers or peers. Embodiments of systems, methods, and devices are described herein for contextual information management at the Medium Access Control (MAC) layer.</p><p num="0007"> According to an exemplary embodiment, the system comprises a plurality of peers communicating via peer-to-peer communication. Each peer device may include a context manager. The first context manager of the first device of the plurality of devices may receive a contextual information request frame with one or more parameters. One or more parameters may indicate at least one of a list of context actions, a list of context identifications, or a response type. Based on the contextual information request frame, the first device has the number of responses remaining, the acknowledgment requirements applicable to the selected one of the one or more context frames, and the one or more context frames. A list of actions applicable to one selected of, a list of context identifications applicable to one selected of one or more context frames, or at least one of one or more context values. Can generate one or more context information response frames that indicate. Contextual information request frames can be received via the medium access control (MAC) layer. In addition, the first device sends a selected one of one or more context frames to the second context manager of the second device of the plurality of devices via the MAC layer. obtain.</p><p num="0008"> This overview is provided to introduce a selection of simplified form concepts, further described below in the form for carrying out the invention. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to the limitations that resolve any or all of the disadvantages described in any part of this disclosure.</p>

0009<figref num="1">FIG. 1 is a block diagram illustrating a context management architecture for proximity communication, according to an exemplary embodiment.</figref><figref num="2">FIG. 2 is a block diagram illustrating a proxy-based context management architecture according to an exemplary embodiment.</figref><figref num="3">FIG. 3 is a call flow for remote context operation according to an exemplary embodiment.</figref><figref num="4A">FIG. 4A illustrates a call flow for local context operation according to an exemplary embodiment.</figref><figref num="4B">FIG. 4B illustrates another call flow for local context operation, according to another embodiment.</figref><figref num="5">FIG. 5 illustrates a call flow for proxy-based contextual behavior according to an exemplary embodiment.</figref><figref num="6">FIG. 6 illustrates another call flow for proxy-based contextual behavior according to another exemplary embodiment.</figref><figref num="7">FIG. 7 illustrates a call flow for session-based contextual behavior according to an exemplary embodiment.</figref><figref num="8A">FIG. 8A illustrates an exemplary and non-limiting modified and / or extended general MAC frame format according to an embodiment.</figref><figref num="8B">FIG. 8B illustrates an exemplary and non-limiting frame control field format according to an embodiment.</figref><figref num="9A">FIG. 9A illustrates an exemplary and non-limiting modification and / or extended beacon frame format according to an embodiment.</figref><figref num="9B">FIG. 9B illustrates an exemplary and non-limiting superframe information format according to an embodiment.</figref><figref num="9C">FIG. 9C illustrates an exemplary and non-limiting application frame information format according to an embodiment.</figref><figref num="10A">FIG. 10A illustrates an exemplary and non-limiting association request frame format according to an embodiment.</figref><figref num="10B">FIG. 10B illustrates an exemplary and non-limiting association response frame format according to an embodiment.</figref><figref num="10C">FIG. 10C illustrates an exemplary and non-limiting isolation request frame format according to an embodiment.</figref><figref num="10D">FIG. 10D illustrates an exemplary and non-limiting isolation response frame format according to an embodiment.</figref><figref num="10E">FIG. 10E illustrates an exemplary and non-limiting association update notification frame format according to an embodiment.</figref><figref num="10F">FIG. 10F illustrates an exemplary and non-limiting association update response frame format according to an embodiment.</figref><figref num="11A">FIG. 11A illustrates an exemplary and non-limiting P2PNW channel distribution request frame format according to an embodiment.</figref><figref num="11B">FIG. 11B illustrates an exemplary and non-limiting P2PNW channel distribution response frame format according to an embodiment.</figref><figref num="11C">FIG. 11C illustrates an exemplary and non-limiting intra-P2PNW channel distribution request frame format according to an embodiment.</figref><figref num="11D">FIG. 11D illustrates an exemplary and non-limiting intra-P2PNW channel distribution response frame format according to an embodiment.</figref><figref num="12A">FIG. 12A is a system diagram of an exemplary Machine to Machine (M2M) or Internet of Things (IoT) communication system in which one or more disclosed embodiments may be implemented.</figref><figref num="12B">FIG. 12B is a system diagram of an exemplary architecture that can be used within the M2M / IoT communication system illustrated in FIG. 12A.</figref><figref num="12C">FIG. 12C is a system diagram of an exemplary M2M / IoT terminal or gateway device or peer device that can be used in the communication system illustrated in FIG. 12A.</figref><figref num="12D">FIG. 12D is a block diagram of an exemplary computing system in which aspects of the communication system of FIG. 12A can be implemented.</figref>

0010Peer-to-peer (P2P) networks (P2PNW) can be formed by the desired context, such as an application or service. Contextual information from different layers can play a major role in managing P2P communications. As used herein, contextual information generally refers to information that may be used to describe, track, and / or infer the context or situation of a service, application, device, network, or combination thereof. Can point. Examples of contextual information are presented as examples, but not limited to location information, time information, application categories, service power categories, arbitrary user information, multi-hop information, travel information, channel status information, association information, device information. , Other application or service information, etc. Existing approaches to handling contextual information are typically done in an isolated way. For example, contextual information can be stored in layers or entities and is not passed between layers or entities. This approach can be inefficient for P2P communication. For example, when P2PNW is formed, peer discovery / association can involve decisions based on application information and can involve measurements from lower layers. As used herein, peer discovery is used for peers to find one or more other peers prior to peer association to enable P2P proximity communication. Can point to a process. Peer association can refer to the process used on a peer to establish a logical relationship with one or more other peers before P2P data transmission can begin. Peer associations can also be referred to, but not limited to, peer attachments, peering, pairing, or link establishment. According to an exemplary embodiment, contextual information is efficiently managed across different layers for P2P communication.

0011In many cases, existing approaches to working with contextual information do not share contextual information from different applications. In P2P communication, the same contextual information can involve similar procedures. For example, location information can be shared by gaming applications, advertising / shopping applications, and social network applications. According to an exemplary embodiment, contextual information for different applications is efficiently shared and managed so that different peers can request and access contextual information from different applications.

0012In an exemplary embodiment, contextual information is exchanged directly between peers during P2P communication. For example, contextual information (eg, application information, association identifiers, user and / or device information) may be exchanged between peer associations for P2P communication. Described below are messages and reference points for context management in P2P communication. For example, client / server-based and proxy-based MAC tier context management architectures are described below.

0013Various embodiments of context management functions and methods are further described herein. According to one embodiment, efficient contextual behavior can occur between peers or devices, and a single contextual behavioral request can result in multiple MAC frames in response. As described herein, efficient contextual behavior can occur between protocol layers and work on the same peer device. In another exemplary embodiment, proxy-based contextual behavior occurs, allowing a peer to request and act on contextual information on behalf of other peers. In yet another exemplary embodiment, session-based contextual behavior may occur and multiple (eg, two) peers or devices may establish a MAC tier session to continuously exchange contextual information. it can.

0014Proximity communication applications (implements) can benefit from exchanging contextual information between peers. As an example, four peers can be in close range while playing an online game. Peers are, for example, in context, such as, but not limited to, their location information, movement information, device capabilities (eg, whether they support voice, screen size, etc.), user information (eg, level or familiarity in the game), etc. Information can be exchanged. Such exchange of contextual information can improve the user's gaming experience. The above example illustrates a scenario where contextual information is exchanged between four devices, but it is understood that the exchange of contextual information can occur between any number of peer devices, if desired. Will.

0015Referring to FIG. 1, the exemplary context management system 100 may include one or more peer devices 102, each communicating via proximity communication. As illustrated, the context management system 100 includes a first peer device 102a and a second peer device 102b. As used herein, a peer device may simply be referred to as a peer, and a peer can refer to any device that is connected to another device via a communication channel or network. Peers are in tablets, smartphones, music players, game consoles, personal digital assistants, laptops, PCs, medical devices, connected cars, smart meters, home gateways, monitors, alarms, sensors, set-top boxes, printers, 2G networks. Mobile station (MS), user equipment (UE) in a 3G network, or IEEE 802.15 (Wireless Personal Area Network (WAN)) Can be a full-featured device (FFD) or mitigation feature (RFD) in one or a group of networks. As an embodiment, the peer may have a hardware architecture illustrated in Figure 12C, which or a variant thereof is more fully described below, or the peer is a computing system illustrated in Figure 12D. Can have an architecture of, which is also described more fully below. It will be appreciated that the exemplary system 100 has been simplified to facilitate explanations of the subject matter disclosed and is not intended to limit the scope of this disclosure. In addition to or in place of systems such as System 100, other devices, systems, and configurations may be used to implement the embodiments disclosed herein, and all such embodiments. Is considered to be within the scope of this disclosure.

0016With reference to FIG. 1, system 100 may include one or more context managers 104. Each peer device 102 in system 100 may include a context manager (CM) 104. The device context manager 104 can be a hardware and / or software module that runs on the device's processor that manages the context information associated with one or more peer devices. The illustrated first peer 102a includes a first context manager 104a and the illustrated second peer 102b includes a second context manager 104b. The peer device 104a includes a higher layer than the physical (PHY) layer 106a, the medium access control (MAC) layer 108a, and the MAC layer 108a, which is referred to as the higher layer 110a. The peer device 104b includes a higher layer than the physical (PHY) layer 106b, medium access control (MAC) layer 108b, and MAC layer 108b, which is referred to as the higher layer 110b. Context managers 104a and 104b can function on medium access control (MAC) layer 106, and therefore context managers 104a and 104b can be generally referred to as, for example, MAC layer logic functions. Other MAC layer functions, such as MAC layer logical functions 112a and 112b, may reside on the peer device 104 at MAC layer 108. MAC layer logic functions 112a and 112b may include functionality such as discovery, association, relay, etc., for example. Each of the context managers 104 may maintain a context database within their respective peer devices. Contextual information can be stored in the context database. The context database may contain contextual information associated with the peer device on which the context database resides. In addition, or as an alternative, the context database provides contextual information associated with other peer devices that are located separately from the context database.

0017The context manager, eg, the first CM104a, may issue context management related requests to another context manager, eg, the second CM104b. The context manager 104 may also receive a request from another context manager 104 and generate a response to the request. According to an exemplary embodiment, the first context manager 104a may receive requests from the local higher layer 106a, the local MAC function 112a, and the local physical (PHY) layer 106a. CM104a may respond to such a request. The CM104a can be directly accessed by other MAC logical functions 108a, such as discovery, association, relay, etc. CM104a can interact directly with higher layer 110a and PHY layer 108a through interlayer primitives, eg, one or more applications.

0018Continuing with reference to FIG. 1, the CM of the peer device, eg, the first CM104a of the first device 102a, has a CM interface to the CM of another peer, eg, the second CM104b of the second device 104b. Communication is possible through the MAC layer frame via (Icm) 114. A client / server model can be used according to exemplary embodiments when at least two context managers communicate with each other. For example, when the first CM104a communicates with the second CM104b, one of the context managers 104a and 104b can act as a client and the other of the context managers 104a and 104b can act as a server. Therefore, CM104 may be referred to as client CM (CMC) or server CM (CMS). The client CM can send the request to the server CM and wait for a response from the server CM. In one exemplary embodiment, the server CM can simultaneously communicate with multiple other context managers on other peers via multicast / broadcast. In an exemplary scenario where a higher layer, PHY layer, or MAC layer feature cannot find the requested context information from the local CM (CM on the same peer), the local CM makes a request for the requested context information. By sending, you can contact a remote CM (CM on another peer). The CM may perform context analysis or actions such as context filtering, context summarization, context aggregation, etc.

0019Referring to FIG. 2, an exemplary proxy-based context management system 200 may include one or more peer devices 102 communicating with each other via proximity communication. As illustrated, system 200 includes a first CM104a that can act as a client CM and a second CM104b that can act as a server CM. According to an exemplary embodiment, the exemplary system 200 includes a context manager proxy (CMP) 202 capable of communicating with one or more context managers 104. It will be appreciated that the exemplary system 200 has been simplified to facilitate explanations of the subject matter disclosed and is not intended to limit the scope of this disclosure. In addition to, or in place of, systems such as System 200, other devices, systems, and configurations may be used to implement the embodiments disclosed herein, and all such embodiments. Is considered to be within the scope of this disclosure.

0020Still referring to FIG. 2, according to the illustrated sequence, the CM102a can also be referred to as the context manager client (CMC) 102a and the CM102b can also be referred to as the context manager server (CMS) 102b. The CMC102a can communicate indirectly with the CMS102b via the CMP202. Context managers 104a and 104b, as well as CMP202, may function on medium access control (MAC) layer 106, and therefore CMP202 and context managers 104a and 104b may be generally referred to as MAC layer functions. In addition, CM104 of peer device 102 can function as a combination of CMC, CMP, and / or CMS. Referring to FIG. 2, according to an illustrated embodiment, the CMC104a may issue one or more requests 204 to the CMP202, and the CMC102a may receive one or more responses 206 from the CMP. When the CMP202 receives the request 204a from the CMC104a, the CMP202 may perform various functions. For example, CMP202 may, if desired, translate request 204a into a format that CMS104b can understand. The CMP may automatically transfer request 204b, which may be a translated request, to CMS 104b. In response to request 204b, CMS104b may send response 206a to CMP202, and CMP202 may then send response 206b to CMC104b. Alternatively, the CMP202 may send the response 206b directly to the CMC104a without contacting the CMS104b. The CMS104 may receive the translated request 204b from the CMP202 and return the response 206a to the CMC104a. As an example, one game player in a group of peer players may act as a CMP 202 to manage and control the exchange of contextual information between players. As a further example, CMP202 in a game scenario allows contextual information to be shared and discovered by other peers.

0021The context manager 102 as described above with respect to FIGS. 1 and 2 is presented as an example and includes, but is not limited to, various behaviors such as remote context behavior, local context behavior, proxy-based context behavior, and session-based context behavior. Can be carried out. In the remote context action embodiment, one peer's CM performs actions on contextual information maintained by other context managers of different peers. The remote context operation may include, for example, adding context information, reading context information, updating context information, joining context information, aggregating multiple instances of context information, and the like. According to an exemplary embodiment, the local context behavior is the function of the CM of the peer, eg, the first CM104a of the first peer device 102a, and other layers of that peer device, eg, other MAC layers of the peer device 102a. Refers to contextual actions performed with or from 112a or PHY layer 106a. As a further example, if the first CM104a does not have the context information required to perform a particular action, then the CM104a has a remote context action to contact the remote CM, eg, a second CM104b. Can be utilized. Proxy-based contextual behavior refers to the behavior of a CM acting as a proxy to coordinate communication between the CMC and CMS (see Figure 2). Referring to FIG. 1, as an example, the first CM104a and the second CM104b may establish a session at the MAC layer before exchanging contextual information. Thus, subsequent contextual behavior can be referred to as session-based contextual behavior, which can result in an efficient exchange of contextual information between peer devices 102a and 102b.

0022Here, with reference to FIG. 3, an example of a remote context operation is illustrated, in which the remote context operation is performed by the first peer 102a and the second peer 102b, in particular by the first CM104a and the second CM104b. Will be done. According to an exemplary embodiment, at 302, the first CM104a transmits a contextual information request frame to the second CM104b. The context request frame can be generally referred to as a message and may include various fields or parameters such as, for example, a list of context actions, a list of context identifications, response instructions, and the like. Thus, the second CM104b may receive one or more parameters indicating at least one of a list of context actions, a list of context identifications, or a response type. Contextual information request frames can be received via the medium access control (MAC) layer. The list of contextual actions may indicate the required actions to be performed by the second CM104b. The first CM104a may request one or more operations, for example, a plurality of operations within one context request frame. The list of context identifications may indicate the context in which the action will be performed. Therefore, the context ID can identify the context entity in the context database. Context entities can refer to parameters, datasets, applications, services, peer devices, and so on. The response instruction may indicate whether the response from the second CM104b to the first CM104a should be transmitted in one MAC frame or in multiple separate MAC frames.

0023Continuing with reference to FIG. 3, at 304, the second CM104b may transmit a contextual information response frame to the first CM104a. In some cases, the response to the first CM104a may be too long to be contained within a single MAC frame. Therefore, in such a case, multiple MAC frames may be used. A context response frame can generally be referred to as a message, for example, various fields or parameters such as the number of remaining responses, acknowledgment (ACK) instructions, list of actions, list of context identification (ID), context values, etc. Can include. Therefore, based on the context information request frame, the second device 102b, in particular the second CM104b, has the number of remaining responses, an acknowledgment applicable to the selected one of one or more context frames. A requirement, a list of actions applicable to a selected one of one or more context frames, a list of context identifications applicable to a selected one of one or more context frames, or one. It is possible to generate one or more context information response frames indicating at least one of the above context values. The context information request frame can be transmitted via the MAC layer. In an exemplary embodiment, the number of remaining response parameters is how many responses, especially how many contextual response frames, remain to be sent by the second CM104b after the response is sent at 304. Is shown. The ACK instruction may indicate whether an acknowledgment is required for the context response frame sent at 304. For example, if an acknowledgment is required, the first CM104a may send an acknowledgment at 306. The ACK instruction may also indicate that an acknowledgment is required for each of the remaining responses, or that an acknowledgment is required for only a certain number (eg, some) of the responses. A list of actions can indicate one or more actions that correspond to one or more responses. Illustrative behavior is presented as an example and is limited Not, but includes "acquire", "read", or "report". The list of context IDs can indicate the context entities that correspond to one or more responses. The context value can include the requested context information or the value of the associated context information. As an example, the requested context information or context entity can be in terms of speed, so the context value can be one or more speed values (eg, 30 mph, 65 mph, etc.). As another example, the requested context information can point to the temperature associated with the peer device, so the context value that can be read or reported can be the temperature value.

0024In 306, according to an illustrated embodiment, the first CM104a transmits a context response ACK frame to the second CM104b. As mentioned above, the message sent at 304 may request such an acknowledgment that provides confirmation that the context response frame at 304 was received by the first CM104a. At 308, the second CM104b may send the remaining contextual response to the first CM104a. The response sent in 308 may include parameters that are at least similar to those described above with reference to step 304. At 310, the first CM104a sends a context response ACK to the second CM104b. In one exemplary embodiment, some or all of the steps described above are repeated until all the responses required by the request in 302 are transmitted from the second CM104b to the first CM104a. Therefore, although two context response frames are illustrated in Figure 3, it will be appreciated that any number of context response frames can be requested, if desired. Further, it will be appreciated that any number of acknowledgments in the response can be transmitted, if desired. Furthermore, the number of acknowledgment frames illustrated is equal to the number of acknowledgment frames in the response, but the number of acknowledgments in the response can vary compared to the number of acknowledgment frames in the exemplary embodiment. ..

0025Here, with reference to FIGS. 4A and 4B, an example of a local context operation is illustrated, the local context operation is performed by the first peer 102a, in particular by the first CM104a. Referring to FIG. 4A, according to an illustrated embodiment, at 402, the higher layer 110a, PHY layer 106a, or MAC layer function 108a issues a context request primitive to the first CM 104a. Therefore, the first CM104a of the first peer device 102a receives the context request primitive from another layer or MAC layer function of the first peer device 102a. This primitive can be, for example, a primitive identifier (ID) that can indicate the type of primitive, a list of required context actions to be performed, and a context ID that can indicate the context ID at which the action will be performed. It may contain various information such as a list of. In a 404, according to an illustrated embodiment, the first CM104a transmits a context confirmation primitive to a higher layer 110a, PHY layer 106a, or MAC layer function 108a. A primitive in a 404 may contain a primitive ID that indicates the type of primitive. The primitive sent in 404 may further contain one or more context values, which may represent the value of the requested context information.

0026In particular, with reference to FIG. 4B, according to an illustrated embodiment, in 406, the first CM104a transmits a context indicating primitive to a higher layer 110a, PHY layer 106a, or MAC layer function 108a. This primitive may include, for example, a primitive ID indicating the type of primitive, a list of context actions that may indicate the action to be performed, and a list of context IDs that may indicate the context ID at which the action will be performed. Can include. At 408, higher layer 110a, PHY layer 106a, or MAC function may issue context response primitives to the first CM104a on the same peer (peer device 102a). This primitive may have a primitive ID indicating the type of primitive and a context value indicating the value of the requested context information.

0027FIG. 5 illustrates an exemplary proxy-based context management system 500 that may include one or more peer devices 102 that communicate with each other over proximity communication. As illustrated, system 500 has a first CM104a of a first peer device 102a, a second CM104b of a second peer device 102b, a third CM104c of a third peer device 102c, and a fourth. Includes a fourth CM104d of peer device 102d. According to an illustrated embodiment, the first CM104a acts as the context manager client (CMC) 104a, the second CM104b acts as the context manager proxy (CMP) 104b, and the third and The fourth context managers 104c and 104d act as cotext manager servers 104c and 104d, respectively. It will be appreciated that the exemplary system 500 has been simplified to facilitate explanations of the subject matter disclosed and is not intended to limit the scope of this disclosure. In addition to or in place of systems such as System 500, other devices, systems, and configurations may be used to implement the embodiments disclosed herein, and all such embodiments. Is considered to be within the scope of this disclosure.

0028Still referring to FIG. 5, at 502, the first CM104a of the first peer device 102a sends a context response frame to the second CM104b of the second peer device 102b. An exemplary context request frame is described above with reference to FIG. At 504, CM104b looks up its local context database. In an exemplary embodiment, if CM104b finds sufficient context information in the database to respond to a context request from 502, the second CM104b sends a context response frame to the first CM104a in 504. Can be. An exemplary context response frame is described above with reference to FIG. Alternatively, according to an illustrated embodiment, in 503, the second CM104b can transform the context request into a format understood by another CM, eg, the third CMS104c. At 506, the second CM104b transmits the converted context request frame to the third CM104c of the third peer device 102c. At 508, the third CM104c sends a context response frame to the second CM104b. At 510, the second CM104b may transmit the context request frame to another CM, such as the fourth CM104d of the fourth peer device 102d. At 512, the fourth CM104d may send a context response frame to the second CM104b of the CMP. At 513, the second CM104b may aggregate the responses received from the third and fourth context managers 104c and 104d. It will be appreciated that the illustrated CM104b aggregates two responses, but optionally any number of responses can be aggregated by a CM acting as a CMP. In 514, according to the illustrated embodiment, the second CM104b acts as a CMC, according to the illustrated embodiment, the responses aggregated within one or more context response frames.

0029FIG. 6 illustrates the system 500 depicted in FIG. 5, while FIG. 6 shows another embodiment of proxy-based contextual behavior according to another exemplary embodiment. Referring to FIG. 6, in 602, according to the illustrated embodiment, a second CM104b acting as a CMP sends a context request frame to a first CM104a acting as a CMS according to the illustrated embodiment. To do. In some cases, prior to 602, the second CM104b may receive requests from the third CM104c of the third peer 102c and the fourth CM104d of the fourth peer 104d, which are at 602. Trigger a second CM104b to send a request. According to the embodiment depicted and illustrated in FIG. 6, the third CM104c and the fourth CM104d act as context manager clients. At 604, the first CM104a sends a context response frame to the second CM104b. At 606, the second CM104b can analyze the received response. The second CM104b may automatically transfer at least some, for example, all contextual response frames to the third CM104c at 606. At 608, the third CM104c sends a context response ACK to the second CM104b. The acknowledgment of the exemplary context response is described above with reference to FIG. In step 610, the second CM104b may automatically transfer at least some, for example, all contextual response frames to the fourth CM104d. The fourth CM104d may receive the context response frame and, at 612, may transmit the context response ACK to the second CM104b.

0030Here, with reference to FIG. 7, an example of session-based contextual behavior is illustrated, where session-based contextual behavior is performed by first peer 102a and second peer 102b, in particular the first CM104a and second. Implemented by CM104b of. In 702, according to an exemplary embodiment, the first CM104a sends a context start frame to the second CM104b, requesting the start of a context exchange session 700. At 704, the second CM104b sends a context-initiating ACK frame to the first CM104a that approves the request for the context exchange session 700. Therefore, context exchange session 700 begins at 706. In step 706, the first CM104a sends a context request frame to the second CM104b, as described above. At 708, the second CM104b sends a context response frame to the first CM104a. Steps 710 and 712 repeat steps 706 and 708, respectively. It will be appreciated that any number of context request frames and context response frames can be exchanged between the first and second CM104a and 104b, if desired. As an embodiment, in 710, the first CM104a transmits a second context request frame to the second CM104b. At 712, the second CM104b transmits a second context response frame to the first CM104a in response to the second context request frame. In step 714, the second CM104b sends a context request frame to the first CM104a. The second CM104b can piggyback the context request at 714 when the second CM104b sends a context response to the first CM104a (at 712). Therefore, the message at 712 is less than the message sent at 714. Can also include some, for example, all content. In an exemplary embodiment, the second CM104b can also send a context request before the first CM104a finishes requesting context information from the second CM104b. In 716, according to an illustrated embodiment, the first CM104a transmits a context response frame to the second CM104b. At 718, the first CM104a sends a context end frame to the second CM104b, requesting that the current context exchange session 700 be stopped. In 720, according to an exemplary embodiment, the second CM104b acknowledges the context termination acknowledgment frame that requires the context exchange session 700 to be stopped, the first CM104a. And thereby end the context exchange session 700.

0031Contextual information is widely used in peer-aware communication (PAC) to form P2PNW and enable communication within P2PNW. However, contextual information is not specified in either existing IEEE 802.15 or 802.11 MAC frames. As described herein, to enable the exchange of contextual information, and to enhance MAC functionality such as context-aware discovery, context-aware association, context-aware synchronization, and context-aware power control. For efficiency, modifications and / or extensions to the current MAC frame may be implemented and new information elements (IEs) may be defined, as disclosed below. Further, in certain embodiments, the modified and extended frame formats and IE described herein can be used to implement the context information request frame and context information response frame described above.

0032In certain embodiments, a frame format is used, which can be a general MAC frame with new fields in the MAC header related to contextual information that facilitates context-aware discovery, association, power control, channel management, and synchronization procedures. Can be done. New beacon frames can also be used with new fields that define superframe structures and application frames. A new management frame can be used to support associations, isolation, reassociations, and association update requests and responses, along with new fields that define the properties of the association and new fields that indicate relevant contextual information. Another new management frame can be a power control request and response frame that contains new fields that convey information about context and power control. Yet another new management frame can be a common control / data channel (CCDCH) or dedicated control / data channel (DCDCH) request or response frame that contains new fields that convey the distribution of channel resources within the superframe. CCDCH is defined for P2PNW-to-P2PNW communication and is shared by nearby super VL, sub VL, or peers of services or applications. As an example, but not limited to, CCDCH is used for common control messages between adjacent P2PNWs, paging or broadcast messages to adjacent P2PNWs, or short, high-priority data broadcast to adjacent P2PNWs. Can be done. DCDCH is defined for intra-P2PNW communication and is shared by VL, sub-VL, and peers within P2PNW. As an example, but not limited to, DCDCH is a VL, sub VL, common control message between peers, a VL, sub VL, or paging or broadcast message to a peer in P2PNW, or a VL, sub in P2PNW. Short, priority broadcast to VL, or peers

0033In addition, in one embodiment, new information elements (IE) that include contextual information IE that conveys contextual information for P2PNW management and communication, and context and power control information IE that conveys the most important information for power control procedures. ) Can be used. Further details about these frames and IE are specified herein.

0034FIG. 8A illustrates an embodiment of a modified MAC frame format 800 that may be used in connection with the context management procedures described herein. In Figures 8A-B, 9A-C, 10A-F, and 11A-D, the fields shown in bold, italic, and underline are new or modified fields, and they contain new subfields. obtain. Other fields may have the same meaning as defined in the existing IEEE 802.15.4 and 802.11 standards.

0035As shown, frame 800 generally comprises a MAC header 802 and a MAC payload 804. In one embodiment, all fields in the frame may be requested except for the auxiliary field 816 and the auxiliary security header 818. In certain embodiments, the sequence number field 808 and the auxiliary security header 818 may have the same meaning as defined in the IEEE 802.15.4 standard.

0036In this embodiment, the frame control field 806 conveys control information such as the frame type, the required type of acknowledgment message, and the addressing mode. FIG. 11B illustrates an embodiment of format 500 of the frame control field. In certain embodiments, the frame type, frame hold, frame version, security enable, and IE current field may have the same meaning as defined in the IEEE 802.15.4 standard. In one embodiment, all fields within frame control field 806 may be mandatory.

0037Frame types and subtypes 824, 826 can be mandatory and at the same time indicate the type of frame, i.e. the function of the frame. In one embodiment, there are four basic frame types: beacon, management, data, and acknowledgment. Each type of frame can have several subtypes. In addition, the meaning of subtype fields can vary for different frame types. Tables 1, 2, 3, and 4 below define the combinations of frame types and subtypes that can be used in one embodiment. Numerical values are given in these tables, but not at the bitwise level. Other values for each subtype may be used. Further details for each frame type are provided below.

0038<tables num="1"><img id="000003" he="148" wi="158" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0039<tables num="2"><img id="000004" he="105" wi="129" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0040<tables num="3"><img id="000005" he="45" wi="103" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0041<tables num="4"><img id="000006" he="70" wi="120" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0042Still referring to FIG. 8B, in some embodiments, the request ACK type field 828 in the frame control field 806 may specify which acknowledgment frame is expected. For example, the request ACK type field can be set as shown in Table 5 below.

0043<tables num="5"><img id="000007" he="79" wi="77" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0044Seeing Figure 8A again, the addressing field can consist of one or more of the source address, destination address, transmit hop address, and receive hop address. The source and destination address fields can convey the source and destination addresses of the frame. The transmit hop address and receive hop address fields can be prepared for multi-hop scenarios and carry address information for intermediate peers. The transmission hop address is the address of the peer sending this frame. The receive hop address is the address of the peer for receiving this frame. The presence of fields for transmit hop addresses and / or receive hop addresses can be indicated by addressing field instructions.

0045As shown in FIG. 8A, the MAC frame format 800 may further include an addressing field instruction field 810, which may include an indication of the existence of a transmit hop address and a receive hop address within the addressing field 812. The source and destination addresses can always be in addressing field 812, but the presence of transmit and receive hop addresses can be an option for multi-hop scenarios. For example, for a one-hop transmission, none exist, and for the first hop within a multi-hop transmission (ie, the original source is sending a frame), only the receive hop address exists and is transmitted. The hop address is the same as the source address, only the transmit hop address exists for the last hop in the multihop transmission, the receive hop address is the same as the destination address, and the others in the multihop transmission. Both the transmit hop address and the receive hop address are included for the hop of. In addition, the frame can be a relay frame when the addressing field indication is set up as the last two examples (last hop and other hops).

0046As further shown in Figure 8A, the P2PNW / APP ID field 814 field may include a P2P network ID or application ID. All peers participating in a P2P network (NW) may have a locally unique P2PNW / APP ID. If the P2PNW ID has not been determined when the frame is sent, this field may convey the application ID. Since P2PNW can be formed by an application or service, the P2PNW ID can be a network identifier that can be used to define and distinguish an application-specific P2PNW. Due to the distributed nature of proximity services, P2PNW IDs can be locally unique.

0047The P2PNW ID is, but not limited to, the CAID or application ID that indicates the desired service or application (eg Facebook on social networks, Netflix for video streaming, etc.), the location information that indicates the location of the P2PNW, and the peer that generated the P2PNW ID. It may include an ID and a network sequence number that can be used to distinguish existing P2PNWs with the same contextual information. The P2PNW ID is a concatenated structure in which each piece of information is assigned several information bits and all the pieces of information are concatenated, or all pieces of information are summed through some mathematical calculations such as XOR and hash. Can be generated using different structures, such as parallel structures.

0048Based on different control schemes, P2PNW IDs can be generated and assigned by different parties in the network. In an embodiment of a centralized control scheme, the P2PNW ID can then be generated by the Super VL notifying the VL, or the VL will generate the P2PNW ID and broadcast it within the beacon, the Super VL and other Can notify VL. In an embodiment of a hybrid control scheme, the VL may generate a P2PNW ID, broadcast it within a beacon, and notify other VLs. In an embodiment of a distributed control scheme, a peer wishing to form a P2PNW (ie, a peer defining a new application frame) will generate a P2PNW ID, broadcast a beacon, and all within the proximity range of the P2PNW ID. Can notify peers.

0049Still referring to FIG. 8A, field 816 of the auxiliary field may contain fields that are optional but important for some functionality. For example, it may include a context category field indicating an application or service category, such as an emergency service, social network, smart office, etc. As another embodiment, a hopper indicator field may be included to indicate whether the frame sender is ready to relay other frames for the multihop discovery process.

0050FIG. 9A illustrates an exemplary beacon frame format 830. Beacon frames can play an important role in forming P2PNW and enabling P2P communication. Can be used to convey contextual information for discovery procedures, define new superframes and / or application frames throughout the channel management process, demarcate frames / slots for synchronization, and facilitate power control procedures. ..

0051Beacon frames can be used for discovery and can convey contextual information as well as P2PNW information. The subtype field for the beacon frame can be split into two parts, as shown in Table 1. The beacon subtype may define a specific beacon frame type, and the "with respect to discovery" bit is if the beacon holder wishes to be discovered by providing the contextual information required for discovery. Can be set to "1". This bit may be set to "0" if the beacon holder is not desired to be found. Some beacons define both superframes and application frames, but some define only application frames.

0052Table 1 above defines a valid combination of frame type and subtype fields for the frame control field for Beacon Frame 830. Each type of beacon frame can be uniquely mapped to the control scheme and the role of the beacon transmitter (ie, super VL / VL / peer). Beacon frames do not require any ACK. If the beacon message conveys one or more IEs, the IE current field can be set as true, otherwise it can be set as false. Depending on whether the beacon is relayed, the addressing field indication (not shown) and the addressing field 832 are configured correspondingly. The P2PNW ID field 834 can be communicated within the beacon. The context category field 836 may be included to provide context for discovery and / or synchronization procedures. If the beacon is sent for discovery, the hopper indicator field 838 should be present.

0053With respect to the beacon payload, still referring to FIG. 9A, the frame information field 840 can be part of the beacon payload and can consist of two components: superframe information and application frame information. As can be seen in Table 1, superbeacons can convey both superframe information and application frame information. Application beacons under centralized or hybrid control can only convey application frame information. A common application beacon under hybrid control can include both superframe information and application frame information. Peer beacons under distributed control can convey contextual information for discovery. A common peer beacon under distributed control can contain both superframe information and application frame information. Finally, a dedicated peer beacon under distributed control can only convey application frame information.

0054FIG. 9B shows an exemplary format for superframe information 840a that can be provided within the beacon frame information field 840. Beacons that convey superframe information can also define the start of a new superframe. As shown in FIG. 9B, the length of the superframe can always be equal to the beacon spacing, so there is no beacon spacing field in the superframe information. The number of CCDCH slots 842 can indicate the number of time slots provided by CCDCH, which follows the beacon frame. The CCDCH slot size 844 can define the slot size of each CCDCH slot. Application frame list 846 may include a list of items for describing application frames contained within the current superframe, each of which is given a time period within the superframe. Each item in the application frame list describes a different application frame and can consist of application information and application frame offset. The application frame offset may indicate a time offset between the start point of the application frame and a time reference such as the start point within the superframe. This field can be used for synchronization purposes.

0055FIG. 9C illustrates an exemplary format for application frame information 840b that can be provided within the beacon frame information field 840. The application frame length 848 may indicate the total length of the new application frame. The number of DCDCH slots 850 can indicate the number of time slots contained within the DCDCH, which follows the beacon frame. DCDCH and CFP can have the same slot size, which is defined in the slot size field. The super / common beacon offset field 852 may indicate where the superbeacon or common beacon is located in terms of time offset. This field can be used for synchronization purposes.

0056Referring again to Beacon frame format 830 in FIG. 9A, other Beacon payload fields may contain information from one or more higher layers.

0057Association-related procedures can play an important role in forming and updating P2PNW. Various frame formats designed for association, separation, reassociation, and association update procedures are considered herein. Figure 10A illustrates the format of association request frame 860, where all listed fields in the MAC payload portion can be required. Frame types and subtypes are configured as shown in Table 2 and may indicate that this is an association request frame. Long or full addresses can be used within the association request frame. The association request frame does not request any ACK. Instead, the association response may be requested as a reply to the association request. If the association request message conveys one or more IEs, the IE current field should be set as true, otherwise it should be set as false. Depending on whether the association request is relayed, the addressing field instructions and addressing fields (not shown) are configured accordingly as described herein. The P2PNW ID can be communicated within the association request.

0058With respect to the MAC payload of association request frame 860, device capability 862 can be a different type of capability of the peer sending the request. For example, this field may include one or more indicators of the transmitting data rate capacity, battery / power consumption capacity, and / or security capacity of the transmitting peer. In IEEE 802.15.8, P2PNW is formed by the desired application. Associations can be categorized as device-based, service-based, and / or user-based associations. Peers can maintain multiple applications and therefore multiple different types of associated connections. The association type field 864 may indicate the type of association that is expected to be established. Depending on the particular application, service-based or user-based associations may be established, but in multi-hop scenarios device-based associations may be used more commonly.

0059The request duration field 866 of the association request frame 860 may be set by the requester to indicate the length of time that the association connection is expected to be active. The VL indicator field 868 may indicate whether the sender of the request is VL. Response type field 870 can be used to indicate optional fields that may be requested within other MAC payload fields as part of the corresponding association response message. Multi-hop instruction field 872 may indicate whether the association request is relayed to peers outside the receiving one-hop range (ie, multi-hop association). The other MAC payload portion of the association request frame 860 may include optional fields, examples of which are shown in Table 6 below.

0060<tables num="6"><img id="000008" he="151" wi="140" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0061FIG. 10B illustrates an exemplary association response frame 880. Within the header of frame 880, the frame types and subtypes are configured as shown in Table 2 and may indicate that this is an associated response frame. The long or full address can be used within the association response frame 880. The associated response frame does not require any ACK. If the association response message conveys one or more IEs, the IE current field can be set as true, otherwise it can be set as false. Depending on whether the association response is relayed, the addressing field indication and addressing field in the header of frame 880 may be configured accordingly. The P2PNW ID can be communicated in the association response. Neither the context category nor the hopper directive field may be used in the associated response message.

0062For the MAC payload of association response frame 880, the fields of responder device capability 882, association type 884, VL instruction 892, and multihop instruction 894 have the same usage as described herein for association request messages. May have (see, eg, Figure 10A and associated text). The association ID 888 can be an identifier that identifies the association between the two peers. In certain embodiments, the association ID can be generated similar to the P2PNW ID generation. The association decision field 886 may indicate whether the association request is accepted. Note that in this context, "acceptance" can mean that all parameters in the association request are acceptable.

0063The allocation duration field 890 may indicate the duration of the association to be established. The responder determines the duration based on the request duration in the association request. This can be a different value than the request duration of the association request. The assigned short address may include a short address if the requested short address field is set to true in the request message. Based on the response type in the association request, the association response may contain the requested information specified in the other MAC payload portion of the request. In addition to the fields shown in Table 6, additional and alternative fields may be included in the response message, examples of which are illustrated in Table 7 below.

0064<tables num="7"><img id="000009" he="86" wi="146" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0065The reassociation request frame can have a structure very similar to the structure of the association request, as described herein. The main difference between the two structures is that the reassociation request can include the required association ID field in the MAC payload.

0066FIG. 10C illustrates an exemplary separation request frame 900. At frame 900, the fields of the multi-hop indication 908, the number of associated peers 910, and the multi-hop peer ID 912 can be the same as in the association request frame (see, for example, Figure 10A and the associated text). A separation request message may be sent to the other side of the association to notify that the association will be terminated soon. The ACK type required in the frame control field of the header may indicate whether a separate response message is requested. Separation reason field 904 may indicate why the isolation is scheduled to be shut down. In certain embodiments, possible reasons may include link failure, application termination, and resource limitations. Separation duration field 906 may indicate the duration of separation. This can be used to temporarily suspend or terminate an association by indicating that the association will be active after a duration.

0067FIG. 10D illustrates an exemplary isolation response frame 914 that can be used to ensure that the association is broken after receiving the isolation request. In some cases, the peer receiving the isolation request message does not need to send the isolation response. This may depend on the configuration of the ACK type required in the frame control field of the header. The isolation state field 918 of frame 914 may indicate that the association is permanently disconnected. Alternatively, the isolation state field 918 may indicate that the association is temporarily disconnected for a period of time, which in turn will activate the association upon expiration of the time period. Is shown.

0068Figure 10E shows an exemplary association update notification frame 920 that can be used to notify the other side that one or more attributes of an existing association should or have been updated. Illustrates. In this frame, update association information field 924 may include one or more information fields with information about existing associations that need to be updated. Both required or optional fields in the association request frame and response frame can be included in the update association information field.

0069Figure 10F illustrates an exemplary association update response frame 926 that can be used to verify the association attribute updates noted by the association update notification frame. The update status field 930 of this frame indicates whether all requested update association information is updated. The content of this field may indicate whether such information is fully updated, partially updated, or rejected altogether. The update association information field 932 is one of two association information: the request update association information in the non-updated association update notification frame and the association information requested by the sender of the association update response to be updated. Or both can be included.

0070Channel management defines superframe structure and channel access in proximity. A superframe can consist of a CCDCH and one or more application frames, each of which can be further divided into a DCDCH and a contention-free period. Channel management frames can be classified into CCDCH requests, CCDCH responses, DCDCH requests, and DCDCH response frames, as shown in Table 2. All these frames can be used to compete for and distribute channel resources.

0071FIG. 11A illustrates an exemplary P2PNW channel allocation request frame 940 that can be used to broadcast a request on a CCDCH in close proximity for the distribution of radio resources. The VL indicator field 942 of this frame may indicate whether the sender is VL. In embodiments of distributed control schemes, this field is always false. The desired application frame length field 944 may indicate the desired duration of the application frame that the sender attempts to build. The super VL ready field 946 may indicate whether the sender is ready to act as a super VL. This field can be mandatory. The desired application beacon location field 948 can be an optional field indicating when the application beacon is being broadcast. This field can only exist if the sender has knowledge of the superframe structure and is already in sync with the P2PNW.

0072FIG. 11B illustrates an exemplary P2PNW channel distribution response frame 950 that can be transmitted over CCDCH after the P2PNW channel distribution request frame 940. The super VL indicator field 952 in this frame may indicate whether the response is sent from the super VL. In embodiments of hybrid and distributed control schemes, this field can always be false. The response determination field 954 may indicate whether the corresponding P2PNW channel distribution request is acceptable. Reason of refusal field 956 can be used to indicate the reason why the request is rejected. For example, the required time period may overlap, in whole or in part, with the time period allocated to the application frame. Adjustment Proposal Field 958 can be a voluntary field that may include proposals for available time periods. Adjustment proposals can be given higher priority if the response is from Super VL.

0073Figure 11C illustrates an exemplary P2PNW intra-channel distribution request frame 960, which is transmitted via DCDCH and can be used to request one or more time slots within an application frame. In one embodiment, the sender of frame 960 may know the application frame standard when broadcasting a channel distribution request within P2PNW. The sub VL indicator field 962 may indicate that the requesting party is a sub VL or peer. In embodiments of distributed control schemes, this field is always set up as a peer. The desired number of slot fields 964 may indicate the number of time slots requested by the sender. The slot size may be fixed for the entire application frame and peers may only be allowed to request the number of slots for transmission. The desired slot location field 966 can be an optional field indicating the location of the desired time slot within the application frame.

0074Figure 11D may be sent as a reply to the P2PNW the channel distribution request, exemplary P2PNW the channel distribution response message illustrate sage 970. The VL indicator field 972 of this frame indicates whether the response message is sent by VL. In embodiments of distributed control schemes, this field is always false. The fields of Response Decision 974, Reason for Refusal 974, and Adjustment Proposal 978 may have the same usage as those of the fields used within the P2PNW channel distribution response frame (see, eg, Figure 11B and associated text). ).

0075As mentioned above, power control request frames (eg, frame type = 1; frame subtype = 8) can be used to request context and power control information within proximity. Table 8 lists some exemplary and additional fields that may be provided within the MAC payload of the power control request frame according to one embodiment (eg, frame payload field 822 of MAC payload 804 of frame format 800). In one embodiment, the information in Table 8 can be exchanged only once within the proximity range. Only when any of this information is changed will it be included in the power control request for information exchange. Other power control related information, such as service power category, transmitted power, and received signal quality, may be included in one or more CPCI IEs, as further described below.

0076<tables num="8"><img id="000010" he="81" wi="143" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0077In one embodiment, the power control response may be transmitted when the peer receives the power control request message. As mentioned above, the power control response message may provide the requester with power control information of the peer receiving the power control request. The information contained in the power control response message is similar to the information provided in the power control request.

0078Information Elements (IE) can provide a flexible, extensible, and easily implementable way to encapsulate information for efficient message exchange. IE can be either part of the MAC header or the MAC payload. In the exemplary frame format 800 illustrated in FIG. 8A, field 820 is provided to hold IE. Multiple IEs can be concatenated within a single frame.

0079In certain embodiments, the contextual information IE may convey the contextual information of the peer sending the frame. Since P2PNW can be organized and managed based on contextual information, contextual information IE can be of greater importance and can be treated as header IE in the MAC header. Examples of contextual information IE according to one embodiment are provided in Table 9 below.

0080<tables num="9"><img id="000011" he="71" wi="155" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0081Table 10 below lists the IE exemplary fields for communicating CPCI within a power control request or response frame.

0082<tables num="10"><img id="000012" he="78" wi="143" file="JP2016527770A_D0001.tif" img-format="tif" img-content="drawing" /></tables>

0083In other embodiments, contextual and CPCI information can be communicated within an 802.11 or 802.11 beacon frame with new or modified fields similar to those illustrated in Figure 8A.

0084FIG. 12A is a schematic representation of an exemplary Machine to Machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. For example, the context manager described with reference to Figure 1-7 may reside on the various devices depicted in Figure 12A, as further described below. In general, M2M technology provides components for IoT / WoT, and any M2M device, gateway, or service platform can be an IoT / WoT component as well as an IoT / WoT service layer.

0085As shown in FIG. 12A, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 can be a fixed network (eg, Ethernet®, fiber, ISDN, PLC, etc.) or a wireless network (eg, WLAN, cellular, etc.), or a network of heterogeneous networks. For example, the communication network 12 may consist of a plurality of access networks that provide content such as voice, data, video, messaging, and broadcast to a plurality of users. For example, the communication network 12 is one of code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), and the like. The above channel access method can be adopted. Further, the communication network 12 may include other networks such as, for example, a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fusion personal network, a satellite network, a home network, or a corporate network.

0086As shown in FIG. 12A, the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain refers to the area network, usually behind the M2M gateway. The field domain includes the M2M gateway 14 and the terminal device 18. It will be appreciated that any number of M2M gateway devices 14 and M2M terminal devices 18 can be included in the M2M / IoT / WoT communication system 10 if desired. The gateway device 14 or the terminal device 18 can be configured as a peer device in the system that implements contextual information management according to the above-described embodiment. The gateway device 14 and / or the terminal device 18 may be configured as a peer device 102, and thus each of the gateway device 14 and the terminal device 18 may include a context manager 104. Further, each of the gateway device 14 and / or the terminal device 18 may include a context manager proxy such as CMP202. Each of the M2M gateway device 14 and the M2M terminal device 18 is configured to transmit and receive signals over a communication network 12 or a direct wireless link. The M2M gateway device 14 allows wireless M2M devices (eg, cellular and non-cellular) and fixed network M2M devices (eg, PLC) to communicate either through an operator network such as communication network 12 or directly through a wireless link. Make it possible. For example, the M2M device 18 may collect data and transmit the data to the M2M application 20 or M2M device 18 over a communication network 12 or a direct wireless link. M2M device 18 may also receive data from M2M application 20 or M2M device 18. .. In addition, data and signals can be transmitted to and received from the M2M application 20 via the M2M service layer 22, as described below. The M2M device 18 and gateway 14 communicate over a variety of networks, including, for example, cellular, WLAN, WPAN (eg, Zigbee®, 6LoWPAN, Bluetooth®), direct wireless links, and wired. obtain. The terminal device 18 and the gateway device 14 may communicate over various networks to exchange context management messages, as described above. For example, the peer-to-peer communication described above can occur directly between a plurality of terminal devices 18, directly between a plurality of gateway devices 14, or directly between a terminal device 18 and a gateway device 14.

0087Also referring to FIG. 12B, the illustrated M2M service layer 22 in the field domain provides services for the M2M application 20, the M2M gateway device 14, the M2M terminal device 18, and the communication network 12. It will be appreciated that the M2M service platform 22 can communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12, if desired. The M2M service layer 22 can be implemented by one or more servers, computers, and the like. The M2M service layer 22 provides the service capability applied to the M2M terminal device 18, the M2M gateway device 14, and the M2M application 20. The functions of the M2M service layer 22 can be implemented in various ways, for example, as a web server, in a cellular core network, in the cloud, and so on.

0088Similar to the illustrated M2M service layer 22, the M2M service layer 22'residents in the infrastructure domain. The M2M service layer 22'provides services for the M2M application 20'and the underlying communication network 12'in the infrastructure domain. M2M service layer 22'also provides services for M2M gateway device 14 and M2M terminal device 18 within the field domain. It will be appreciated that the M2M service layer 22'can communicate with any number of M2M applications, M2M gateway devices, and M2M terminal devices. M2M service layer 22'can interact with service layers from different service providers. The M2M service layer 22'can be implemented by one or more servers, computers, virtual machines (eg, cloud / compute / storage farm, etc.).

0089Also referring to Figure 12B, M2M service layers 22 and 22'provide a core set of service delivery capabilities that can be leveraged by a variety of applications and vertical lines. These service capabilities allow M2M applications 20 and 20'to interact with devices to perform functions such as data collection, data analysis, device management, security, billing, and service / device discovery. In essence, these service capabilities remove the burden of implementing these functionality from the application, thus simplifying application development and reducing the cost and time to market. Service layers 22 and 22'also allow M2M applications 20 and 20'to communicate through various networks 12 and 12'in connection with the services provided by service layers 22 and 22'.

0090The context manager of the present application can be implemented as part of the service layer. As used herein, the service layer can refer to a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. Both ETSI M2M and one M2M use a service layer that may include the context manager described herein. ETSI The service layer of M2M is called the service capacity layer (SCL). The embodiments described herein can be implemented as part of the SCL and the messages can be based on various protocols such as MQTT or AMQP. SCLs are M2M devices (which are referred to as device SCL (DSCL)), gateways (which are referred to as gateway SCL (GSCL)), and / or (which are referred to as network SCL (NSCL)). Can be implemented within a network node. The oneM2M service layer supports a set of common service functions (CSF) (eg, service capabilities). Instantiation of one or more specific types of CFS is called a Common Service Entity (CSE) and can be hosted on different types of network nodes (eg infrastructure, intermediate nodes, purpose-built nodes). it can. In addition, the context managers described herein can be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) for access. In addition, the context manager of the present application may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services such as the context manager of the present application. it can.

0091M2M applications 20 and 20'may include, but are not limited to, applications in various industries such as transportation, health and wellness, connected homes, energy management, asset tracking, and security and monitoring. As mentioned earlier, M2M service layers that launch across devices, gateways, and servers in other systems include, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery, And supports features such as traditional system integration and provides M2M applications 20 and 20'for these features as services.

0092FIG. 12C is a system diagram of an exemplary M2M device 30 such as, for example, an M2M terminal device 18 or an M2M gateway device 14. The M2M device 30 may be configured as a network node for performing context management according to the above-described embodiment, for example, proxy-based context management. As shown in FIG. 12C, the M2M device 30 includes a processor 32, a transmitter / receiver 34, a transmission / reception element 36, a speaker / microphone 38, a keypad 40, a display / touchpad / indicator 42, and a non-processor. It may include removable memory 44, removable memory 46, power supply 48, Global Positioning System (GPS) chipset 50, and other peripherals 52. It will be appreciated that the M2M device 30 may contain any subcombination of the elements described above, while remaining consistent with the embodiment. The display / touchpad / indicator 42 may generally be referred to as a user interface, according to exemplary embodiments. A user interface, also referred to as a context management interface, may allow a user to monitor, manage, and / or configure context management on a peer device, such as a gateway or other network node. For example, a user interface may allow a user to configure or trigger the exchange and management of contextual information between different peers. The user interface may be configured to display the contextual information request frame or contextual information response frame described above. Therefore, various context parameters (eg, context value, context ID, number of remaining responses, etc.) may be displayed by the display / touchpad / indicator 42.

0093Processor 32 is a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microprocessor, and an application specific integrated circuit (SP). It can be an ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and so on. The processor 32 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that allows the M2M device 30 to operate in a wireless environment. Processor 32 may be coupled to transmitter / receiver 34, which may be coupled to transmit / receive element 36. Although FIG. 12C depicts the processor 32 and the transmitter / receiver 34 as separate components, it will be appreciated that the processor 32 and the transmitter / receiver 34 can be integrated together in an electronic package or chip. Processor 32 may communicate with application layer programs (eg, browsers) and / or wireless access layer (RAN) programs. The processor 32 may perform security operations such as authentication, security key matching, and / or encryption operations at, for example, the access layer and / or the application layer.

0094The transmit / receive element 36 may be configured to transmit the signal to or receive the signal from the M2M service platform 22. For example, in embodiments, the transmit / receive element 36 can be an antenna configured to transmit and / or receive RF signals. The transmission / reception element 36 may support various network and wireless interfaces such as WLAN, WPAN, cellular and the like. In embodiments, the transmit / receive element 36 can be, for example, an emitter / detector configured to transmit and / or receive an IR, UV, or visible light signal. In yet another embodiment, the transmit / receive element 36 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmit / receive element 36 may be configured to transmit and / or receive any combination of wireless or wired signals.

0095In addition, although the transmit / receive element 36 is depicted in FIG. 12C as a single element, the M2M device 30 may include any number of transmit / receive elements 36. More specifically, the M2M device 30 may employ MIMO technology. Thus, in embodiments, the M2M device 30 may include two or more transmission / reception elements 36 (eg, a plurality of antennas) for transmitting and receiving radio signals.

0096The transmitter / receiver 34 may be configured to modulate the signal transmitted by the transmit / receive element 36 and the signal received by the transmit / receive element 36. As mentioned above, the M2M device 30 may have multimode capability. Thus, the transmitter / receiver 34 may include a plurality of transmitters / receivers to allow the M2M device 30 to communicate via multiple RATs such as UTRA and IEEE 802.11.

0097Processor 32 may access information from any type of suitable memory, such as non-removable memory 44 and / or removable memory 46, and store data therein. For example, as described above, the processor 32 stores the context information derived from the non-removable memory 44 and / or the removable memory 46, and whether there is context information that accesses the context information and satisfies the context information request. Can be determined. The non-removable memory 44 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from memory that is not physically located on the M2M device 30, such as on a server or home computer, and store data there.

0098Processor 32 may be configured to receive power from power 48 and distribute and / or control power to other components within the M2M device 30. The power supply 48 can be any suitable device for powering the M2M device 30. For example, the power supply 48 may include one or more dry cell batteries (eg, nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-hydrogen (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc. Can include.

0099Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (eg, longitude and latitude) about the current location of the M2M device 30. It will be appreciated that the M2M device 30 can acquire location information via any public location determination method while remaining consistent with the embodiment.

0100Processor 32 may also be coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripherals 52 include accelerometers, e-compasses, satellite transmitters and receivers, sensors, digital cameras (for photos or videos), universal serial bus (USB) ports, vibrating devices, television transmitters and receivers, hands-free headsets, and Bluetooth. It may include modules (registered trademarks), frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

0101FIG. 12D is a block diagram of an exemplary computer system 90 in which, for example, the M2M service platform 22 of FIGS. 8A and 8B can be implemented. The computer system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, such software being stored or stored anywhere or by any means. Be accessed. Such computer-readable instructions may be executed within the central processing unit (CPU) 91 to run computer system 90. In many known workstations, servers, and peripheral computers, the central processor 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is a voluntary processor, distinctly different from the main CPU 91, that performs additional functions or assists the CPU 91.

0102During operation, the CPU 91 fetches, decodes, and executes instructions and transfers information to and from other resources via system bus 80, which is the computer's primary data transfer path. Such a system bus connects the components within the computer system 90 and defines the medium for data exchange. The system bus 80 typically includes a data line for transmitting data, an address line for transmitting addresses, and a control line for transmitting interrupts and operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

0103Memory devices attached to system bus 80 include random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM93 generally contains stored data that cannot be easily modified. The data stored in RAM82 can be read or modified by CPU91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by memory controller 92. The memory controller 92 may provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 may also provide a memory protection function that isolates processes in the system and separates system processes from user processes. Therefore, a program running in the first mode can only access the memory mapped by its own process virtual address space, and unless memory sharing between processes is set up, the virtual address space of another process. Unable to access the memory inside.

0104In addition, the computer system 90 may include a peripheral controller 83, which is responsible for transmitting instructions from the CPU 91 to peripherals such as the printer 94, keyboard 84, mouse 95, and disk drive 85.

0105The display 86, controlled by the display controller 96, is used to display the visual output produced by the computer system 90. Such visual output may include text, graphics, video graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes electronic components required to generate a video signal transmitted to the display 86.

0106In addition, the computer system 90 may include a network adapter 97 that can be used to connect the computer system 90 to an external communication network such as network 12 in FIGS. 8A and 8B.

0107Any or all of the systems, methods, and processes described herein are described herein when an instruction is executed by a machine such as a computer, server, M2M terminal device, M2M gateway device, etc. It is understood that it can be embodied in the form of computer-executable instructions (ie, program code) stored on a computer-readable storage medium that performs and / or implements the systems, methods, and processes described. To. Specifically, any of the steps, actions, or functions described above may be implemented in the form of such computer executable instructions. Computer-readable storage media include both volatile and non-volatile, removable and non-removable media, implemented by any method or technique for storing information, but such computer-readable media. The storage medium does not contain a signal. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROMs, digital versatile discs (DVDs) or other optical disc storage devices, magnetic cassettes, magnetic tapes, magnetic disc storage. It includes, but is not limited to, devices or other magnetic storage devices, or any other physical medium that can be used to store desired information and is accessible by a computer.

0108Certain terms are used for clarity in describing preferred embodiments of the subject matter of the present disclosure as illustrated in the figures. However, the claimed subject matter is not intended to be limited to the particular term so selected, and each particular element behaves similarly to achieve similar objectives, all technical. It should be understood that it includes equivalents.

0109The present specification includes the disclosure of the present invention, including the best aspects, and the one skilled in the art making and using any device or system, and any incorporated method. , Examples are used to make it possible to practice the present invention. The patentable scope of the invention may include other embodiments defined by the claims and recalled to those skilled in the art. Such other embodiments have structural elements that are not different from the literal words of the claim, or include equivalent structural elements with very slight differences from the literal words of the claim. It is intended to be within the scope of the claims.