Multiple simultaneous active gateways in personal IoT network

Abstract

Methods and procedures are described for supporting management of multiple simultaneously active gateways within a PIN. A method may include receiving, by a PEMC, from two PIN units, two PIN join requests including PIN client profile information indicating that a corresponding PIN unit may act as a gateway; determining to configure the PIN unit as a gateway based on each item of PIN client profile information; receiving a PIN join request including PIN client profile information from a third PIN unit; determining to assign the first PIN unit as a default gateway for a third PIN unit and to assign the second PIN unit as a backup gateway based on the PIN client profile information for each PIN unit; and sending a notification to the PIN units indicating that the first PIN unit acts as a default gateway for the third PIN unit and the second PIN unit acts as a backup gateway.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 378,208, filed on October 3, 2022, entitled "Methods and Procedures to Support Multiple Simultaneously Active Gateways within a Personal IoT Network", which is incorporated herein by reference. Background of the Invention

[0003] As more companies release new products in different market segments and consumers adopt the technology for personal use in their homes, Internet of Things (IoT) devices are becoming ubiquitous. Due to their practicality and convenience, smart home devices such as large and small appliances, lighting and switches, security cameras, motion and water detectors, meter readers, door locks, and garage door openers, as well as personal wearable devices such as AV / VR glasses, headsets, and medical and health sensors, are beginning to be widely adopted by consumers. 3GPP has recognized the rapidly growing market opportunity and has initiated various efforts within the standards organization to support the creation of Personal IoT Networks (PINs) that connect IoT devices together for communication within and outside the PIN.

[0004] One such effort can be found in the 3GPP SA6 working group, where application enabling layers are defined to specify application layer APIs that help companies quickly and easily incorporate 3GPP technology into their products. SA6 research has started to define application enabling functions for supporting Personal IoT Network Applications called PINAPPs. The results of this research are positively reflected in 3GPP TR 23.700 - 78.

[0005] Within a PIN, a single PIN unit with gateway capabilities (PEGC) may become overloaded or may become unresponsive. For this reason, support for multiple simultaneously active PEGCs within the same PIN may be beneficial. Multiple simultaneously active PEGCs within the same PIN allow load balancing of PIN communication across the individual PEGCs. This load balancing can minimize network congestion within the PIN and can reduce PIN message delivery latency. Additionally, redundancy is provided in the event that a PEGC becomes overloaded and / or becomes unresponsive. When multiple simultaneously active PEGCs are available within the same PIN, if / when a particular PEGC becomes overloaded and / or becomes unresponsive, the PIN unit can transition to using another PEGC to relay its messages. This transition can occur seamlessly without the need for a PIN unit with management capabilities (PEMC) to detect the PEGC problem, assign the role of the PEGC to another PIN unit, or notify other PIN units of the new PEGC. This can enable the PIN unit to transition to using a different PEGC in a pipelined manner if needed / when needed, thus saving time and overhead. Summary of the Invention

[0006] Methods for managing multiple simultaneously active PEGCs within a PIN are disclosed herein. In the proposed method, a PEMC may receive a PIN join request from a first PIN unit that includes PIN client profile information of the first PIN unit. The PIN client profile information of the first PIN unit may indicate that the first PIN unit is capable of acting as a gateway (or PEGC) within the PIN. The PEMC may also receive a second PIN join request from a second PIN unit that includes PIN client profile information of the second PIN unit. The PIN client profile information of the second PIN unit may also indicate that the second PIN unit is capable of acting as a gateway (or PEGC) within the PIN. The PEMC may determine that the first and / or second PIN unit is capable of acting as a gateway (or PEGC) of the PIN based on the PIN client profile information of the corresponding PIN unit. The PEMC may configure the first and / or second PIN unit as a gateway (or PEGC) of the PIN based on the PIN client profile information of the corresponding PIN unit. The PEMC may receive a third PIN join request from a third PIN unit that includes third PIN client profile information. The PEMC may determine that the third PIN unit requires one or more gateways (or PEGCs). The PEMC may assign the first PIN unit as the default gateway for the third PIN unit and the second PIN unit as the alternate gateway for the third PIN unit based on the PIN client profile information of the first, second, and third PIN units. The PEMC may send a notification to the first PIN unit that includes information indicating that the first PIN unit acts as the default gateway for the third PIN unit. The PEMC may send a notification to the second PIN unit that includes information indicating that the second PIN unit acts as the alternate gateway for the third PIN unit. The PEMC may send a response to the third PIN unit. The response may indicate that the first PIN unit acts as the default gateway and the second PIN unit acts as the alternate gateway for communicating messages between the third PIN unit and other units within the PIN. The PEMC may detect the expiration of a heartbeat timer for the first PIN unit. The expiration of the heartbeat timer may indicate that the first PIN unit is no longer capable of acting as a gateway (or PEGC) for the third PIN unit. Based on the expiration of the heartbeat timer, the PEMC may configure the second PIN unit as the default gateway for the third PIN unit.

[0007] This description is provided in part to introduce in a simplified form a portion of the concepts that will be further described in the detailed description section that follows. This description is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additionally, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure. Brief Description of the Drawings

[0008] The following detailed description can be better understood when read in conjunction with the accompanying drawings. For purposes of illustration, examples are shown in the drawings; however, the subject matter is not limited to the specific elements and means disclosed. In the drawings:

[0009] Figure 1 An exemplary PINAPP architecture is shown;

[0010] Figure 2 An exemplary process is shown for assigning the role of PEGC to a PIN unit in a reactive manner when other PIN units join the PIN;

[0011] Figure 3 An exemplary process is shown for PEMC to establish a PIN and proactively assign the role of PEGC to multiple PIN units during PIN establishment;

[0012] Figure 4 An exemplary process is shown for a PEGC item PEMC to notify that it can no longer continue in the role of PEGC;

[0013] Figure 5 An example is shown of a PIN unit being unable to communicate with the default PEGC and switching to using an alternate PEGC;

[0014] Figure 6 An exemplary process is shown for a PEGC to notify another PEGC of its impending failure;

[0015] Figure 7 An exemplary process is shown of a PIN encountering failures when attempting to communicate with both the default and alternate PEGCs;

[0016] Figure 8 An exemplary process is shown of a PIN unit handling a failure of a PEGC and subsequently assuming the role of PEGC in response.

[0017] Figure 9 Another exemplary process is shown of a PIN unit communicating with a PIN unit outside the PIN via an alternate PEGC;

[0018] Figure 10 An exemplary process is shown for PEGC operation based on location;

[0019] Figure 11 An exemplary process is shown for PEGC operation based on scheduling;

[0020] Figure 12 An exemplary GUI for PIN management is shown;

[0021] Figure 13 An exemplary GUI for client PIN configuration is shown;

[0022] Figure 14A An exemplary communication system that can be an aspect of the methods and apparatuses described and claimed herein;

[0023] Figure 14B A block diagram showing an exemplary apparatus or device configured for wireless communication;

[0024] Figure 14C A system diagram showing an exemplary radio access network (RAN) and core network;

[0025] Figure 14D A system diagram showing another exemplary RAN and core network;

[0026] Figure 14E A system diagram showing another exemplary RAN and core network;

[0027] Figure 14F A block diagram showing an exemplary computing system; and

[0028] Figure 14G A block diagram showing another exemplary communication system. DETAILED DESCRIPTION

[0029] Methods for supporting the management of multiple simultaneously active PEGCs within a PIN are described herein. This includes several proposed PIN profile enhancements that define additional information units that can be exchanged between the PIN server, PEMC, PEGC, and PIN units within a PIN, thereby allowing and assisting in the management of multiple simultaneously active PEGCs. Using these new information units, several procedures are also proposed. These procedures can include, among others: by assigning the role of a PEGC to a PIN unit in response to a new PIN unit joining the PIN, the PEMC can reactively load balance the PIN. To complement this reactive procedure, proactive procedures are also defined, where the PEMC establishes the PIN and, in doing so, proactively assigns the role of a PEGC to multiple PIN members due to the expectation of a large number of PIN units joining the PIN. Procedures are also defined that allow PIN units to react to situations where a PEGC becomes unresponsive or overloaded. In such cases, the procedures define how a PIN unit can transition to using a standby PEGC or trigger the assignment of a new PEGC within the PIN if / when the existing PEGC becomes unavailable or does not meet the requirements of the PIN unit. Procedures are also defined that support transitioning a PIN unit to use a different PEGC based on the location of the PIN unit and PEGC or their operational schedule. The terms "method" and "procedure" as used herein are synonymous and can be used interchangeably.

[0030] An exemplary method may include a PIN having various PIN units that may send PIN client profile information to a PEMC via a PIN join request, and the PEMC uses the PIN client profile information to determine to assign the PIN as a default PEGC and one or more alternate PEGCs, and the PIN units will use the default PEGC or one or more alternate PEGCs to communicate with other PIN units. The client profile information may include one or more of the following: application client key performance indicators (KPIs), application client scheduling, mobility metrics, current location, expected location, access type, and / or PIN group list.

[0031] In addition, a PIN unit may receive updated PIN client profile information from the PEMC, and the PIN unit uses the updated PIN client profile information to determine with which PEGCs to communicate, when to communicate with the PEGCs, and where to communicate with the PEGCs, where the updated client profile information may include one or more of the following: identifiers of the default PEGC and one or more alternate PEGCs, availability scheduling, and location.

[0032] In addition, a PIN unit may receive an indication from the PEMC that allows the PIN unit to transition to the role of a PEGC if / when the default and / or alternate PEGCs become unresponsive to the PIN unit, and transition the PIN unit to the role of a PEGC when it detects that the default and / or alternate PEGCs have become unresponsive.

[0033] In addition, a PIN unit may notify the PEMC if / when the default and / or alternate PEGCs are unresponsive or no longer meet the KPI requirements of the PIN unit.

[0034] In the proposed method, the PEMC may receive PIN client profile information from the PIN unit, and the PEMC uses the PIN client profile information to assign the PIN unit as a default PEGC and one or more alternate PEGCs, where the client profile information may include one or more of the following: application client KPIs, application client scheduling, mobility metrics, current location, expected location, access type, PIN group list.

[0035] In addition, the PEMC may determine that additional PEGCs are needed in the PIN, and the determination may be made in the following cases: when a new PIN unit joins the PIN, when the PEMC fails to receive a heartbeat from a PEGC, or when a notification is received from a PIN unit or a PEGC.

[0036] In addition, the PEMC can compare the information contained in the PIN client profile with the dynamic PIN profile information stored and maintained by the PEMC to determine one or more candidate PIN units that are to transition to the role of the PEGC, where the information can include one or more of the following: an indicator of the ability of the PIN unit to support acting as a PEGC, the current and supported KPIs and schedules of the PEGC, the KPIs and schedules required by the PIN unit application client, the current and expected locations of the PEGC and the PIN unit, and the schedule supported by the PEGC.

[0037] In addition, the PEMC can send a notification to the PIN unit to inform it that it has been assigned the role of the PEGC, where the information can include one or more of the following: a list of PIN units that the PEGC will serve as the default PEGC, a list of PIN units that the PEGC will serve as the backup PEGC, updated schedule information indicating that the PEGC must be available for a specific time window to serve PIN unit communication requests, and a routing authorization policy defining a list of PIN units or PIN groups that the PIN unit is allowed to communicate with by using the PEGC.

[0038] In addition, the PEMC can send updated PIN client profile information to the PIN unit, and the PIN unit uses the updated PIN client profile information to determine which PEGCs to communicate with, when to communicate with the PEGCs, and where to communicate with the PEGCs, where the updated client profile information can include one or more of the following: identifiers of the default PEGC and one or more backup PEGCs, availability schedules, and locations.

[0039] In addition, the PEMC can send an indication to the PIN unit that indicates that the PIN unit is allowed to transition to the role of the PEGC if / when the default and / or backup PEGC becomes unresponsive to the PIN unit.

[0040] In addition, the PEMC can receive a notification from the PEGC or the PIN unit if / when the default and / or backup PEGC for the PIN unit is unresponsive or no longer meets the KPI requirements of the PIN unit.

[0041] In the proposed method, a PIN unit capable of acting as a PEGC can send PIN client profile information to the PEMC within a PIN join request, and the PEMC uses the PIN client profile information to determine the PEGC role assignment for the PIN unit, where the client profile information can include one or more of the following: the supported PEGC schedule, the supported PEGC KPIs, mobility metrics, current location, expected location, access type, and / or battery level.

[0042] In addition, a PIN unit capable of acting as a PEGC can receive dynamic PIN profile information from a PEMC, and the dynamic PIN profile information can include one or more of the following: a list of PIN units that the PEGC will serve as the default PEGC, a list of PIN units that the PEGC will serve as an alternate PEGC, updated scheduling information indicating when the PEGC must be available to service PIN unit communication requests, and a routing authorization policy defining a list of PIN units or PIN groups with which the PIN units served by the PEGC are permitted to communicate.

[0043] In addition, a PIN unit capable of acting as a PEGC can send a notification to the PEMC indicating that the PEGC is unable to continue in the role of PEGC or that another PEGC in the PIN is unresponsive or unable to meet the communication requirements (KPIs, scheduling, etc.) of its assigned PIN units.

[0044] The following abbreviations may be used herein:

[0045]

[0046]

[0047] Figure 1 An exemplary PINAPP architecture defined so far in 3GPP TR 23.700-78 is shown. The architecture defines a PINAPP application enabling layer for managing personal IoT networks. A PIN server can be deployed by a network operator in a data network to provide configuration information to PIN units and can authorize the creation of PINs. A PIN unit can be a node in a PIN (e.g., an endpoint device, a gateway, etc.). A PIN unit with management capabilities (PEMC) can be responsible for PIN management. A PIN unit with gateway capabilities (PEGC) can be responsible for routing traffic between PIN units. Within a PIN unit, there can be a PIN client and one or more application clients.

[0048] A PIN unit can be 3GPP with a SIM card or can be without a SIM card, and the SIM card has an associated 3GPP subscription. A PIN unit without a SIM card can be provided with a 3GPP-defined user identifier to use the 5G network and its services. Alternatively, a PIN unit can be a non-3GPP device operating using different access technologies such as Wi-Fi or Bluetooth.

[0049] PIN communication can occur over a carrier - managed spectrum such as used by the Uu and PC5 interfaces, or can occur over a non - carrier - managed spectrum such as Wi - Fi and Bluetooth. The Uu interface can be defined as the radio interface between a UE and a RAN node or base station, and PC5 is defined as the radio interface for direct communication between two UEs. Both interfaces can use access technologies defined by 3GPP.

[0050] Before creating a PIN, the PEMC can obtain authorization from a carrier - managed PIN server. The PEMC can be controlled by an authorized administrator or user, such as a homeowner or a family member of the homeowner who wishes to create a PIN at home. After being authorized, the PEMC can then create and delete PINs and add or remove PIN units to / from the PIN. The PEMC can also designate a PIN unit to become a PEGC in order to provide data traffic routing functions for the PIN. The routing in this case can be for intra - PIN, inter - PIN, and through the 5GS or 5GS - PIN. Intra - PIN routing can be between the members of a PIN, inter - PIN routing can be between the members of two different PINs, and 5GS - PIN routing can be between the members of a local PIN through the 5G network and a remote PIN member (such as a UE). The remote PIN member can be a member of the local PIN or can be authorized by the PIN server to access the local PIN. In addition to using the PEGC to route intra - PIN traffic, if authorized, a PIN unit can also communicate directly with another PIN unit within the PIN. A PIN unit that is a non - 3GPP device and wishes to join a PIN can be assigned a user identifier by the PEMC in order to communicate over the 5G network and use the services of the 5G network.

[0051] PIN Profile Enhancement

[0052] PIN profile information can include information elements that change statically and dynamically. PIN profile information can be stored and maintained by the PIN server, PEMC, and PEGC. Dynamically changing PIN information can also be exchanged between the PIN server, PEMC, and PEGC based on events (such as a PIN unit joining or leaving, a change in PIN unit capabilities). The type of PIN information, as well as the initiator and receiver, can vary depending on the type of event that occurs and the PIN units involved.

[0053] To support multiple simultaneously active PEGCs within the same PIN, the PIN profile can include one or more new information elements. For example, in Table 1, the PIN profile can include one or more of the following new information elements: Target PIN KPI. In Table 2, the following new information elements are proposed in the dynamic profile: Current PIN KPI, > Supported PEGC KPI, > Current PEGC KPI, > PEGC Scheduling, >> PIN Unit or Group ID, >> PEGC Role, >> Routing Authorization, > PIN Group List, > Capabilities, > Device Identifier, > Battery Level, > PIN E Scheduling, > Heartbeat Time, > Current Location, > Expected Location, > Access Type, > Access Code, > Default PEGC, > Alternate PEGC List, > Application List, >> Application Identity, >> Application KPI, > Assumed PEGC Role, > Current PIN Role, > Supported PEGC Scheduling, > Supported PEGC KPI, PIN Group List, > PIN Group ID, > Maximum Member Count, > Member PINEs, and > Group Endpoints. And in Table 3, the following new information elements are proposed in the PIN client profile: > Application Scheduling, > Application KPI, Mobility, Current Location, Expected Location, Access Type, Battery Level, PIN Group List, Heartbeat Timer, Default PEGC, Alternate PEGC List, Assumed PEGC Role, Current PIN Role, Supported PEGC Scheduling, and Supported PEGC KPI.

[0054] In the tables below, the ">" symbol is used to indicate that an information element is a sub - element of another information element. In the tables below, the ">>" symbol is used to indicate that an information element is a sub - element of another sub - element.

[0055] Table 1, PIN Profile Enhancement

[0056]

[0057]

[0058] Table 2 - Dynamic PIN Profile Enhancement

[0059]

[0060]

[0061]

[0062]

[0063]

[0064]

[0065] Table 3 - PIN Client Profile Enhancement

[0066]

[0067]

[0068] The information units in Tables 1 and 2 can be managed by PIN entities associated with the profile (such as PIN servers, PEMC, PEGC, and PINE), and the information units in Table 3 can be managed by PIN units associated with the profile. Information units that play important roles in PEGC operations will be briefly described later to provide examples of their use. The following description does not intend to describe all possible uses of the information units, nor is it intended to be used to limit the scope of use of the information units.

[0069] Various KPI information units can be configured to provide information for PEGC to respond to and process PIN communications according to the requirements of PIN units. For example, PEMC can compare the application KPIs in Table 1 with the supported PEGC KPIs in Table 2 to determine the appropriate PEGC for PINE services. In addition, PEMC can combine the current PEGC KPIs from Table 2 with the aforementioned KPIs to make determinations regarding PEGC load. Other similar combinations of KPI information units can be envisioned to assist PEGC management.

[0070] Two important information units that may be relevant for PEGC management are the default PEGC and the list of alternate PEGCs. Both can be configured to notify PINE of the PEGC that will serve PIN communication. The default PEGC will be the primary PEGC to relay PIN communication from PINE, and in the event that the default PEGC is unavailable, PINE can communicate with one or more alternate PEGCs to relay PIN communication. It should be noted that the alternate PEGCs can be organized as a prioritized list of alternate PEGCs. If more than one PEGC is listed in the alternate PEGC list, PINE can first communicate with the higher-priority PEGC. In the case where the information unit assuming the PEGC role is configured for PINE, the alternate PEGC list information unit can be a prioritized list of PINEs that assume the role of PEGC in the event that a PEGC cannot act as an alternate PEGC (e.g., due to being out of schedule or in a power-saving mode). For example, the alternate PEGC list can have the following configuration: [PEGC-B, PINE-5, PINE-7]. In this example, the primary alternate PEGC is PEGC-B. When PEGC-A, which is the default PEGC, fails or becomes unresponsive, if PEGC-B cannot act as a PEGC, PINE-5 can assume the role of a temporary PEGC. If PINE-5 also cannot act as a PEGC, then PINE-7 can assume the role of a temporary PEGC. Alternatively, the default PEGC and the alternate PEGC list information unit can be implemented as a single information unit. The first entry in the list can be the default PEGC. The subsequent entries in the list can be the alternate PEGCs. The order of the alternate PEGCs in the list can determine the priority order of the alternate PEGCs.

[0071] Other information units that can assist in PEGC management are the PEGC schedule, the PINE schedule, and the supported PEGC schedules. These schedule information units can be used to determine when a PEGC can act as the default or alternate PEGC, and the PEMC can utilize these information units to configure the default and alternate PEGCs. For example, the schedule can be configured such that PEGC-A will act as the default PEGC from 8 am - 8 pm, and PEGC-B can act as the default PEGC from 8 pm - 8 am. Similar configurations can be envisioned for the alternate PEGCs.

[0072] Several other information units that can assist in PEGC management are as follows: PIN group list, PIN group ID, group endpoints: These information units can be used to form groups of PINE units served by the PEGC. The groups can be "sub-networks" of PINs; access type, access code: Some PIN units can use non-3GPP access, such as Wifi, Bluetooth, and Zigbee. Non-3GPP access can use specific security codes to establish communication between PINEs; current location, expected location: These location information units can help the PEGC and / or PINE determine which PEGC to utilize for relaying PIN communication, especially when the communication is being transported over a 5G network. Context information such as PDU session information can be exchanged, provided, and / or authorized for a new PEGC to support service continuity for the PINE; mobility: This information unit can be used to assist the PEGC in determining whether the PINE is stationary and in a fixed position or mobile and capable of moving around (e.g., within or in and out of the PIN); and heartbeat timer; This information unit controls the frequency at which the PEGC / PINE must contact the PEMC and can be used by the PEMC to detect whether the PEGC / PINE has left the PIN or has become unresponsive if / when the PEMC fails to receive a heartbeat from the PEGC / PINE.

[0073] PEMC Management of PEGC

[0074] Figure 2An exemplary method is shown where a PEGC role can be assigned to a PIN unit to provide load balancing for a PIN with a large number of PIN units. In this example, the PEMC may have received authorization for PIN creation (from the PIN server), and thus a PIN with member PEMC, PEGC-A, and PINEs 1-5 has been established. Subsequently, a new device (PINE-6) may request to join the PIN. When requesting to join the PIN, PINE-6 may provide PIN client profile information to the PEMC. Using this PIN client profile information in combination with the dynamic PIN profile information that the PEMC also maintains, the PEMC can determine that in order not to overload PEGC-A, another PEGC is needed to provide load balancing for PIN communication. The PEMC may then check if any other PIN units support the PEGC capability. The PEMC can perform this check by examining the capabilities that the PIN units may have shared with the PEMC when joining the PIN or that may have been updated later. The PEMC identifies PINE-5 as having the PEGC capability. Subsequently, the PEMC may assign the role of the second active PEGC (PEGC-B) for the PIN to PINE-5. By configuring the list of PIN units assigned to PEGC-A and PEGC-B, the PEMC can load balance the PIN units across the two active PEGCs. Subsequently, the PIN units can be notified of the default and alternate PEGCs to which they are assigned.

[0075] In Figure 2 Step 1, the PEMC may request authorization for PIN creation from the PIN server, and the PIN server may grant the request and provide PIN profile information to the PEMC, such as but not limited to the PIN information defined in Tables 1 and 2.

[0076] In Step 2, the PEMC may establish the PIN and assign the role of the default PEGC to a PIN unit (e.g., PEGC-A). As additional PIN units (PINEs 1-5) join the PIN, the PEMC may configure the PIN clients of these PIN units to use PEGC-A as their default PEGC for PIN communication. The PEMC may also configure PIN profile information for PEGC-A indicating that PEGC-A is acting as the default PEGC for PINEs 1-5. The PEMC may send a PIN profile update regarding the configuration of PEGC-A and PEGC-B as PEGCs to the PIN server.

[0077] In step 3, a new PIN unit (PINE-6) can be added to the PIN. When adding the PIN, PINE-6 can send a PIN addition request to the PEMC. The request can contain PIN client profile information, such as but not limited to the information defined in Table 3. When receiving the request, the PEMC can determine the PEGC that needs to be attached. This determination can be based on the PEMC comparing the information to be included in the PIN client profile of PINE-6 with the PIN profile information maintained and stored by the PEMC. For example, the PEMC can store the PEGC KPIs supported by PEGC-A, and using these KPIs, the PEMC can determine whether PEGC-A can support serving PINE-6 in addition to serving PINE 1-5. The PEMC can make this determination by comparing information such as the minimum required KPIs of the application clients on PINE 1-6 with the maximum KPIs supported by PEGC-A. For example, if the minimum KPIs of PINE 1-6 exceed the maximum KPIs supported by PEGC-A, the PEMC can determine that another PEGC is needed within the PIN to load balance the communication within the PIN across multiple PEGCs.

[0078] In step 4, after determining that a PEGC needs to be attached (i.e., there is only a single PEGC currently in the PIN) to balance the load of the communication within the PIN, the PEMC can then determine whether there are candidate PIN units within the PIN that can assume the role of the PEGC. To make this determination, the PEMC can examine the PIN profile information it stores and maintains, such as but not limited to the information defined in Table 2. Within this PIN profile information, the capabilities supported by each PIN unit that has joined the PIN can be stored. This information can indicate whether the PIN unit supports the ability to act as a PEGC. If a PIN unit can act as a PEGC, additional information such as the KPIs that the PIN unit can support when acting as a PEGC (e.g., the maximum PIN communication request service rate, the maximum PIN communication response time, the maximum number of assigned PIN units, etc.) can also be stored in the PIN profile. Based on this information, the PEMC can identify a PIN unit (e.g., PINE-5) that can assume the role of the PEGC. The PEMC can then configure PINE-5 to act as the default PEGC (PEGC-B) for PINE-6. Additionally, the PEMC can also assign a standby PEGC role for additional robustness and reliability. For example, the PEMC can assign PEGC-B as the standby PEGC for PINE 1-4. The configuration of PINE-5 acting as the default and / or standby PEGC can include the PEMC configuring the PIN profile information for PINE-5, such as but not limited to the information reflected in Table 2. For example, configuring for PINE-5 the PIN role (PEGC) it is currently acting as, the list of PIN units or PIN groups it serves as a PEGC, and whether it is serving as the default or standby PEGC. The PEMC can also share similar information about other active PEGCs in the PIN. Subsequently, PINE-5 selects to accept (or reject) the new PEGC role and begins operating as PEGC-B.

[0079] In step 5, the PEMC can notify (step 5a) PEGC-A of the update to the dynamic PIN profile information indicating that PEGC-B can act as the standby PEGC for PINE 1-4. The PEMC (step 5b) or PEGC-A (step 5c) can also notify PINE 1-4 that PEGC-B can act as its standby PEGC. Optionally, the PEMC or PEGC-A can unicast, multicast, or broadcast the updated information to PINE 1-4 to notify it of standby PEGC-B. Alternatively, to minimize control signaling, the PEMC or PEGC-A can wait until a future communication with PINE 1-4 occurs to provide it with the updated information about standby PEGC-B.

[0080] In step 6, the PEMC can respond to the request of PINE-6. The PEMC can include updated PIN client profile information in this response, such as but not limited to the information embodied in Table 3. For example, this information can include the default PEGC-B and the alternate PEGC-A assigned to PINE-6.

[0081] In step 7, the PEMC can perform a PIN profile update on the PIN server to provide it with updated PEGC configuration information for the PIN. It should be noted that this step can be performed at any time after the PEMC makes a determination to configure a new role for PINE-5 (e.g., after step 3). The PIN profile update can include a role change for PINE-5 and new configurations for the default and alternate PEGCs.

[0082] In the previous example, the decision to assign PEGC roles to PIN units can be made reactively in response to a new PIN unit joining the PIN. Figure 3 An exemplary procedure showing a more proactive approach, where the PEMC establishes a PIN by first assigning roles of PEGCs to two PIN members. During subsequent PIN unit join requests, the PEMC can assign default and alternate PEGCs to the PIN unit to load balance each PEGC. This also provides enhanced robustness and reliability for the PIN in the event that a problem is encountered within one of the PEGCs. For example, if the PIN unit detects that the default PEGC does not respond to its PIN communication request or the default PEGC does not meet the KPIs of the application client of the PIN unit, the PIN unit can utilize the alternate PEGC.

[0083] For example, the PEMC may receive a PIN join request from a first PIN unit that includes the PIN client profile information of the first PIN unit. The PIN client profile information of the first PIN unit may indicate that the first PIN unit is capable of acting as a gateway (or PEGC) in the PIN. The PEMC may also receive a second PIN join request from a second PIN unit that includes the PIN client profile information of the second PIN unit. The PIN client profile information of the second PIN unit may also indicate that the second PIN unit is capable of acting as a gateway (or PEGC) in the PIN. The PEMC may determine that the first and / or second PIN units are capable of acting as gateways (or PEGCs) of the PIN based on the PIN client profile information of the corresponding PIN units. The PEMC may configure the first and / or second PIN units as gateways (or PEGCs) of the PIN based on the PIN client profile information of the corresponding PIN units. The PEMC may receive a third PIN join request from a third PIN unit that includes third PIN client profile information. The PEMC may determine that the third PIN unit requires one or more gateways (or PEGCs). The PEMC may assign the first PIN unit as the default gateway for the third PIN unit and the second PIN unit as the standby gateway for the third PIN unit based on the PIN client profile information of the first, second, and third PIN units. The PEMC may send a notification to the first PIN unit, the notification including information indicating that the first PIN unit acts as the default gateway for the third PIN unit. The PEMC may send a notification to the second PIN unit, the notification including information indicating that the second PIN unit acts as the standby gateway for the third PIN unit. The PEMC may send a response to the third PIN unit. The response may indicate that the first PIN unit acts as the default gateway and the second PIN unit acts as the standby gateway for transmitting messages between the third PIN unit and other units in the PIN. The PEMC may detect the expiration of the heartbeat timer for the first PIN unit. The expiration of the heartbeat timer may indicate that the first PIN unit is no longer capable of acting as a gateway (or PEGC) for the third PIN unit. Based on the expiration of the heartbeat timer, the PEMC may configure the second PIN unit as the default gateway for the third PIN unit.

[0084] The PIN client profile information of the first and second PIN units may include the supported gateway (or PEGC) KPIs, and the third PIN client profile information may include application KPIs. The first PIN unit may be configured to act as the default gateway for the third PIN unit and the second PIN unit may be configured to act as the standby gateway for the third PIN unit based on the supported gateway (or PEGC) KPIs of the first and second PIN units and the application KPIs of the third PIN unit.

[0085] The PIN client profile information of the first and second PIN units may include the supported gateway (or PEGC) scheduling, and the third PIN client profile information may include application scheduling. The first PIN unit may be configured to act as the default gateway for the third PIN unit, and the second PIN unit may be configured to act as the standby gateway for the third PIN unit, based on the supported gateway (or PEGC) scheduling of the first and second PIN units and the application scheduling of the third PIN unit.

[0086] The PIN client profile information of the first, second, and third PIN units may include the location information of the first, second, and third PIN units, respectively. The first PIN unit may be configured to act as the default gateway for the third PIN unit, and the second PIN unit may be configured to act as the standby gateway for the third PIN unit, based on the proximity of the third PIN unit to the first and second PIN units.

[0087] In Figure 3 step 1, the PEMC may request authorization for PIN creation from the PIN server, and the PIN server may grant the request and provide PIN profile information to the PEMC, such as but not limited to the PIN information defined in Table 1 and Table 2.

[0088] In step 2, the PEMC may establish the PIN and determine the PIN units, PEGC-A and PEGC-B, configured to have gateway functionality. The PEMC may make this determination using the target PIN KPIs (such as the minimum PIN communication request service rate, the maximum PIN communication response time, the minimum number of supported PIN units, etc.) defined in the PIN profile information received by the PEMC from the PIN server. Alternatively, the PEMC may be configured by a policy or receive a request from an authorized administrator to have multiple PEGCs that support communication for the PIN. For example, the authorized administrator may be aware of or plan to add a large number of PIN units to the PIN, or may desire a specific level of communication availability, reliability, and robustness for the PIN. The PEMC may send a PIN profile update regarding the configuration of PEGC-A and PEGC-B as PEGCs to the PIN server.

[0089] In step 3, PINE-1 can send a PIN join request to PEMC. PINE-1 can include PIN client profile information in the request, such as but not limited to the information embodied in Table 3. PEMC receives the request and can configure PINE-1 to have PEGC-A as the default PEGC and PEGC-B as the alternate PEGC. Based on the information provided by PINE-1 in its PIN client profile along with the PIN information stored and maintained by PEMC for PEGC-A and PEGC-B, PEMC can select PEGC-A rather than PEGC-B as the default PEGC. For example, PEMC can store the supported KPIs of each PEGC. PEMC can also store information for each PIN unit currently assigned to PEGC-A and PEGC-B (such as identifiers, required KPIs, access types) and whether PEGC-A and PEGC-B are acting as the default or alternate PEGC for each of them. Based on this information, PEMC can determine whether PEGC-A or PEGC-B is a better candidate to act as the default PEGC.

[0090] In step 4, PEMC can notify PEGC-A that it will act as the default PEGC for PINE-1. When notifying PEGC-A, PEMC can share dynamic PIN profile information, such as but not limited to the information embodied in Table 2.

[0091] In step 5, PEMC can notify PEGC-B that it will act as the alternate PEGC for PINE-1. When notifying PEGC-B, PEMC can share dynamic PIN profile information, such as but not limited to the information embodied in Table 2.

[0092] In step 6, PEMC can configure PINE-1 to have PEGC-A as the default PEGC and PEGC-B as the alternate PEGC. When configuring PINE-1, PEMC can share PIN client profile information, such as but not limited to the information embodied in Table 3.

[0093] In step 7, PINE-2 can send a PIN join request to PEMC, and steps 3 - 6 are repeated for PINE-2. PEMC can configure PINE-2 to have PEGC-B as the default PEGC and PEGC-A as the alternate PEGC. PEMC can also notify PEGC-A and PEGC-B of the PEGC configuration.

[0094] In step 8, the PEMC may implement a PIN profile update with the PIN server and provide an updated PEGC configuration. The update may include information such as, but not limited to, the information defined in Table 2. It should be noted that this step may be implemented at any time after step 3.

[0095] The configurations of the default and standby PEGCs can help the PEMC handle emergency situations where the PEGC fails. For example, the PEGC (PEGC-A) may have a low battery and can notify the PEMC that it can no longer act as a PEGC. In another example, the PEGC may become overloaded for the PIN units it serves and notify the PEMC of its overload. For these types of situations, the PEMC can quickly respond to the notification and configure the available standby PEGC (PEGC-B) as shown Figure 4 to act as the new default PEGC. This quick action can maintain the continuity of PIN communication and allow the PEMC time to select a new candidate PEGC.

[0096] In Figure 4 step 1, the PEMC may be authorized to create a PIN and has established a PIN with the following PIN members: PEMC, PEGC-A, PEGC-B, and PINE 1-8. PEGC-A may act as the default PEGC for PINE 1-4, and PEGC-B may act as the default PEGC for PINE 5-8. PEGC-A may be configured as the standby PEGC for PINE 5-8, and PEGC-B may be configured as the standby PEGC for PINE 1-4. The PEMC may send a PIN profile update to the PIN server regarding the configurations of PEGC-A and PEGC-B as PEGCs.

[0097] In step 2, PEGC-A may have a low battery or may be overloaded and thus can no longer meet the KPIs required by the PIN units it serves. Subsequently, PEGC-A may notify the PEMC that it can no longer act as a PEGC or request that some PIN units be unloaded to continue acting as a PEGC. PEGC-A may include dynamic PIN profile information in the notification, such as its current battery level, or the current KPIs indicating its current workload (e.g., average PIN communication request rate, average response time, current number of served PIN units, etc.). Alternatively, when no periodic heartbeat is received from PEGC-A, the PEMC may detect that PEGC-A is not operating.

[0098] In step 3, the PEMC can notify the PEGC-B that it now acts as the default PEGC (instead of the standby PEGC) for PINE 1-4 (or a subset thereof). Although not shown in the figure, similar to steps 4 and 5 defined for Figure 3 the PEMC can also notify (multiple) other PINEs (other than PEGC-B) that it will act as the (multiple) default or standby PEGC.

[0099] In step 4, optionally, the PEMC can unicast, multicast, or broadcast a notification with the new PEGC configuration to PINE 1-4 (or a subset thereof), e.g., that the PEGC-B will act as the new default PEGC. If the PEMC selects other PINEs to act as the new PEGC, the PEMC can include the information of the new PEGC and whether the PEGC will act as the default or standby PEGC. The notification sent by the PEMC can include information such as, but not limited to, the PIN client information defined in Table 3.

[0100] In step 5, the PEMC can implement a PIN profile update with the PIN server and provide the updated PEGC configuration information. The update can include information such as, but not limited to, the information defined in Table 2. It should be noted that this step can be implemented at any time after step 3.

[0101] Standby PEGC operation

[0102] After the PEMC configures multiple PEGCs for the PIN, the PIN unit can dynamically react to the interruption of PIN communication using the configured information. For example, if the PIN unit cannot send its communication to the default PEGC or the default PEGC cannot meet the communication KPIs required by the PIN unit, the PIN unit can alternatively send its communication to the standby PEGC. In addition, the PEMC can also be notified that the default PEGC is unresponsive and take necessary actions (such as finding another PIN unit and assigning the role of the PEGC to it). Figure 5 Such an exemplary scenario is shown.

[0103] In Figure 5 step 1, the PEMC can request authorization from the PIN server to create a PIN. The PIN server can grant the request and provide the PEMC with PIN profile information, such as, but not limited to, the information defined in Table 1.

[0104] In step 2, the PEMC can establish a PIN with PIN members including the PEMC, PEGC-A, PEGC-B, and PINE 1-8. PEGC-A can act as the default PEGC for PINE 1-4, and PEGC-B can act as the default PEGC for PINE 5-8. PEGC-A can be configured as the alternate PEGC for PINE 5-8, and PEGC-B can be configured as the alternate PEGC for PINE 1-4. The PEMC can send a PIN profile update regarding the configuration of PEGC-A and PEGC-B as PEGCs to the PIN server.

[0105] In step 3, PINE-5 can send a communication to PINE-1 through PEGC-B, which is the default PEGC for PINE-5. The communication may not be successful or may not meet the communication KPIs required by PINE-5. As a result, PINE-5 can decide to attempt to send the communication to PEGC-A, which is its alternate PEGC.

[0106] In step 4, PINE-5 can re-send the communication to PINE-1 through PEGC-A, which is the alternate PEGC for PINE-5. When sending the communication to PEGC-A, PINE-5 can also include information indicating the reason for using its alternate PEGC instead of its default PEGC. This information can include an indication that PINE-5 was unable to reach the default PEGC. Alternatively, this information can include an indication that PINE-5 did not receive a communication from PEGC-B that met the KPIs required by the PIN unit. Information can also be provided regarding which KPIs were not met and the magnitude of the gap between the required KPIs and the actually observed KPIs.

[0107] In step 5, PEGC-A can check the dynamic PIN profile information it manages to ensure that PINE-5 is authorized to use the services of PEGC-A and is authorized to send a communication to PINE-1. After a successful check, PEGC-A can forward the communication to PINE-1.

[0108] In step 6, PINE-1 can return a response to PEGC-A for forwarding to PINE-5.

[0109] In step 7, PEGC-A can forward the response received from PINE-1 to PINE-5.

[0110] In step 8, PEGC-A may notify PEMC that PINE-5 has utilized its standby PEGC instead of the default PEGC. When notifying PEMC, PEGC-A may pass the information received from PINE-5 as described in step 4 indicating the reason why PINE-5 chose to use its standby PEGC-A instead of its default PEGC-B.

[0111] In step 9, PEMC may attempt to communicate with PEGC-B to determine whether PEGC-B is still unresponsive and / or to evaluate the load on PEGC-B. If PEMC determines that PEGC-B is not operating or is overloaded, PEMC may select and configure a new default PEGC for PINE 5-8 (or a subset of PINE 5-8) to replace PEGC-B as the default PEGC (e.g., PEMC may implement Figure 4 steps 3-5).

[0112] In step 10, PEMC may implement a PIN profile update with the PIN server and provide the updated PEGC configuration information. The update may include information such as, but not limited to, the information defined in Table 2.

[0113] In some cases, a PEGC may be aware of when it will no longer be able to continue acting as a PIN unit with gateway capabilities, such as when the PEGC may have low power. During these situations, the PEGC may communicate with another PEGC serving the PIN to temporarily take over the gateway capabilities on its behalf. Figure 6 An example is shown where PEGC-B has low power and communicates with PEGC-A to temporarily assume the role of taking on the gateway capabilities on behalf of PEGC-B. PEGC-A may then notify PEMC of the situation and temporarily act as the new default PEGC for PINE 5-8.

[0114] In Figure 6 steps 1-2, PEMC may be authorized as described in Figure 5 steps 1-2 and may establish a PIN.

[0115] In step 3, PEGC-B may have low power or may malfunction for other reasons. PEGC-B may be configured to communicate with PEGC-A, which is the standby PEGC, to request that it act as the new default PEGC for the PIN units served by PEGC-B. PEGC-B may send the PIN management information as shown in Tables 2 and 3 to PEGC-A.

[0116] In step 4, when accepting the new role, PEGC-A can notify PINE 5-8 that PEGC-A will act as the new default PEGC and can indicate the scheduling in which PEGC-A will serve in this capacity. PEGC-A can also notify PINE 1-4 that PEGC-B will no longer act as the standby PEGC. PEGC-A can also notify PEMC that it is temporarily acting as the default PEGC for PINE 5-8 on behalf of PEGC-B and can indicate that it has been notified of the failure of PEGC-B and what the failure code is.

[0117] In steps 5-8, PINE-5 can have communication for PINE-1 and can send the communication to PEGC-A as described in steps 4-7 of Figure 5 .

[0118] In steps 9-10, PEMC can attempt to communicate with PEGC-B to determine whether PEGC-B can continue to act as the PEGC. If PEMC cannot communicate with PEGC-B (e.g., due to PEGC-B being offline and unreachable), then PEMC can configure a new PEGC for PINE 5-8 and notify the PIN server of the new PIN configuration as described in steps 9-10 of Figure 5 .

[0119] If the PIN unit cannot send its communication to the assigned default PEGC or (a) standby PEGC(s), the PIN unit can notify PEMC so that PEMC can take actions such as assigning a new PEGC for the PIN unit to use. Figure 7 An exemplary scenario is shown.

[0120] In Figure 7 step 1, PEMC can request authorization for PIN creation from the PIN server. The PIN server can grant the request and provide PIN profile information to PEMC, such as but not limited to the information defined in Table 1.

[0121] In step 2, PEMC can establish a PIN with PIN members including PEMC, PEGC-A, PEGC-B, and PINE 1-3. PEGC-A can act as the default PEGC for PINE 1, and PEGC-B can act as the default PEGC for PINE 2 and 3. PEGC-A can be configured as the standby PEGC for PINE 2 and 3, and PEGC-B can be configured as the standby PEGC for PINE 1. PEMC can send a PIN profile update regarding the configuration of PEGC-A and PEGC-B as the PEGCs to the PIN server.

[0122] In step 3, PINE-2 can send a communication to PINE-1 through PEGC-B, which serves as the default PEGC for PINE-1. This communication may not be successful. As a result, PINE-2 can decide to attempt to send a communication to PEGC-A, which serves as its backup PEGC.

[0123] In step 4, PINE-2 can send a communication to PINE-1 through PEGC-A, which serves as the backup PEGC for PINE-2. This communication may not be successful. As a result, PINE-2 can decide to notify the PEMC.

[0124] In step 5, PINE-2 sends a notification to the PEMC indicating that both PEGC-A and PEGC-B are unreachable. [PINE-5 sends a request to the PEMC to be assigned a different PEGC]. The PEMC can check whether PEGC-A or PEGC-B is reachable. To perform this check, the PEMC can attempt to contact PEGC-A and PEGC-B. Alternatively, the PEMC can check whether it has received periodic heartbeats from PEGC-A or PEGC-B. If the PEMC determines that both PEGC-B and PEGC-B are unreachable, the PEMC can determine whether another PIN unit in the PIN has the ability to act as a PEGC. The PEMC can make this determination by checking the PIN client profile information shared with the PEMC by each PIN unit when joining the PIN.

[0125] In step 6, after determining that PINE-3 has the ability to act as a PEGC, the PEMC can configure PINE-3 to act as PEGC-C for the PIN. This configuration can be implemented in a manner similar to that described in Figure 2 step 4 as described above.

[0126] In step 7, the PEMC can respond to the notification from PINE-2. The PEMC can include updated PIN client profile information in this response, such as but not limited to the information embodied in Table 3. For example, this information can include the default PEGC-C assigned to PINE-2. Although not shown in Figure 7 it, the PEMC can also notify PINE-1 of the new default PEGC-C.

[0127] In step 8, PINE-2 can send a communication targeted at PINE-1 to PEGC-C.

[0128] In step 9, PEGC-C can forward the request from PINE-2 to PINE-1.

[0129] In step 10, PINE-1 can send a response to PEGC-C.

[0130] In step 11, PEGC-C can forward the response to PINE-2.

[0131] In step 12, PEMC can implement a PIN profile update with the PIN server and provide updated PEGC configuration information. The update can include information such as, but not limited to, the information defined in Table 2. It should be noted that this step can be implemented at any time after step 6.

[0132] In the previous example, both of the two PEGCs configured for the PIN have failed or are unavailable. As a result, PINE-2 has to request help from PEMC to configure a new PEGC to support PIN communication. To address such an emergency situation, configuration parameters can be added to the PIN client profile where PINE can be configured to automatically assume the role of the PEGC in such a case. During the PIN joining procedure, the device can indicate whether it supports PIN gateway capabilities, and PEMC can use this information to configure a specific PIN unit to automatically assume the role of the PEGC if / when the PIN unit detects that its default and alternate PEGCs are unavailable. Figure 8 An exemplary scenario showing PINE assuming the role of the PEGC due to its default and alternate PEGCs being unavailable.

[0133] In Figure 8 step 1 of, PEMC can request authorization for PIN creation from the PIN server. The PIN server can grant the request and provide PIN profile information to PEMC, such as, but not limited to, the information defined in Table 1.

[0134] In step 2, PEMC can establish a PIN and determine to configure PEGC-A and PEGC-B as PIN units with gateway functions. PEGC-A will act as the default PEGC for PINE 1-4, and PEGC-B will act as the alternate PEGC. Similarly, PEGC-B will act as the default PEGC for PINE 5-8, and PEGC-A will act as the alternate PEGC. In addition, PINE 2 and 5 indicate that they have gateway capabilities when joining the PIN. In response, PEMC can specify that in the case where PEGC-A or PEGC-B fails or can no longer act as the default PEGC, PINE 2 and 5 can act as the default PEGC for PEGC-A or PEGC-B respectively. PEMC can send a PIN profile update regarding the configuration of PEGC-A and PEGC-B as PEGCs to the PIN server.

[0135] In step 3, PINE-5 may need to communicate with PINE-1 and may send the communication to PEGC-B which is its default PEGC. PEGC-B may fail and not respond to the communication request from PINE-5.

[0136] In step 4, PINE-5 may detect that PEGC-B does not respond to the communication request. If it has gateway capabilities and is configured by PEMC to assume the role of a PEGC in case the default PEGC (such as PEGC-B) cannot provide gateway services, it may decide to assume the role of the default PEGC.

[0137] In step 5, PINE-5 may notify PEMC that it is assuming the role of a new PEGC replacing PEGC-B. In response, PEMC may notify PEGC-A that PINE-5 (PEGC-C) will act as the new standby PEGC. PEMC may also respond to the notification from PINE-5, thereby indicating authorization for the role change of PINE-5 and may provide PINE-5 with dynamic PIN profile information, such as a new PIN identifier (e.g., PEGC-C) and a list of individual or groups of PIN units that PINE-5 / PEGC-C will serve as the default PEGC and / or standby PEGC. PEMC may also include a routing authorization policy for PEGC-C, which defines a list of other PIN units or groups of PIN units that each PIN unit or PIN group is allowed to communicate with via PEGC-C. Although Figure 8 not shown in, but PEGC-A may also notify PINE 1-4 that PEGC-C can act as the standby PEGC.

[0138] In step 6, PEMC may implement a PIN profile update with the PIN server and provide updated PEGC configuration information. The update may include information such as, but not limited to, the information defined in Table 2. It should be noted that this step may be implemented at any time after step 5.

[0139] In step 7, PEMC may unicast, multicast or broadcast (a) notification(s) to notify PINE 6-8 that PEGC-C will act as the new default PEGC. Although Figure 8 not shown in, but PEMC may also notify PINE 1-4 that PEGC-C can act as the standby PEGC.

[0140] In step 8, PINE-5, which now acts as the new PEGC-C, can forward the PIN communication targeted at PINE-1 to PEGC-A, which acts as the default PEGC for PINE-1. PEGC-A can relay the PIN communication to PINE-1 and can provide the response from PINE-1 to PINE-5 / PEGC-C. Alternatively, since PEGC-C acts as the standby PEGC for PINE-1, PINE-5 can alternatively forward the PIN communication directly to PINE-1( Figure 8 not shown).

[0141] Figure 9 An exemplary process is shown where PINE-7 can attempt to communicate with PINE-11 by communicating with its default PEGC-B, where PEGC-B fails. As a result, PINE-7 can attempt to alternatively use its standby PEGC-A. When doing so, PEGC-A can establish a PDU session to enable PINE-7 to communicate with PINE-11, as this communication can span a 5G network.

[0142] In Figure 9 step 1, a PIN with two PEGCs, namely PEGC-A and PEGC-B, can be established. The PIN can have 10 PIN members, namely PINE 1-10.

[0143] In step 2, PINE-7 may need to communicate with PINE-11, which belongs to another PIN, and send a communication to PEGC-B. The communication can include PINID, PINE-11ID, IP address, port number, and other application-centric data. Even after several attempts, the communication may still not be successful.

[0144] In step 3, PINE-7 can determine that PEGC-B has failed or is currently unavailable. Alternatively, PINE-7 can resend the communication to PEGC-A, which is the standby PEGC for PINE-7.

[0145] In step 4, PEGC-A can receive the communication, and based on the PINID and / or IP address, PEGC-A can determine that the communication needs to be sent through the 5G network. PEGC-A can check the routing authorization rules provided to PEGC-A by the PEMC to check whether authorization for the communication from PINE-7 to PINE-11 is permitted. If PEGC-A finds that the communication is permitted, it can establish a PDU session with the 5G network to carry the communication from PINE-7 to PINE-11.

[0146] In step 5, PEGC-A can send a communication to PEGC-C, which is another PEGC residing in another PIN where PINE-11 resides. PEGC-C then forwards the communication to PINE-11.

[0147] In step 6, PINE-11 can return a response for the communication from PINE-7 via PEGC-C.

[0148] In step 7, PEGC-A can receive the response from PEGC-C and can forward the response to PINE-7.

[0149] Location-based PEGC Operations

[0150] The PEMC can establish a PIN and determine to configure PEGCs at different locations throughout the PIN. By doing so, the PEMC can ensure that the PIN has optimal PEGC coverage across the entire coverage area of the PIN. For example, the PEMC can assign the role of PEGC to PIN units in different rooms or on different floors within a residence or building. Additionally, when the PIN units move around within the PIN, the PEMC can adjust the default and / or standby PEGCs assigned to the PIN units based on their new location. For example, the PEMC can change the default PEGC after the PIN unit moves to a new location within the PIN (e.g., moves to a different room or different floor) so that the default PEGC is closer to the PIN unit. The PEMC can also adjust which PIN units act as the PEGC based on the location of the PIN units within the PIN. For example, the PEMC can assign / re-assign the role of PEGC to PIN units within a specific location within the PIN that has a high concentration of PIN units to ensure that the PEGC can meet the communication KPIs of the PIN units. Figure 10 An example of this is shown.

[0151] In Figure 10 step 1, the PEMC can request authorization for PIN creation from the PIN server, which can grant the request and provide the PEMC with PIN profile information such as but not limited to the information defined in Table 1.

[0152] In step 2, the PEMC can establish a PIN and determine to configure PEGCs at different locations throughout the PIN (e.g., within different rooms or on different floors of a house or building). The PEMC can determine which PIN units will be assigned the role of PEGC by analyzing various information provided in the PIN client profiles of the PIN units that have joined the PIN. For example, the PEMC can consider the current and expected locations of the PIN units, which PIN units are mobile and which are stationary, the application KPIs required by each PIN unit, which PIN units have PEGC capabilities, and the PEGC KPIs supported by each PEGC-capable PIN unit. The PEMC can analyze all or a subset of this information when selecting the PIN units to which the role of PEGC will be assigned. By doing so, the PEMC can ensure that the PEGCs are optimally distributed throughout the PIN near the PIN units to which they are assigned, and that the PEGCs can meet the KPI requirements of their assigned PIN units. For example, the PEMC can assign the roles of PEGC-A and PEGC-B to PEGCs located on different floors or in different rooms within a residence.

[0153] In step 3, PINE-1 joins the PIN and can send a join request to the PEMC. Within this request, PINE-1 can include a PIN client profile. Information such as, but not limited to, the information defined in Table 3 can be included within this profile. For example, PINE-1 can provide its current location, its expected location (if it is a mobile device), and the KPIs required by its application client. Based on this information, the PEMC can select an optimal default PEGC to assign to the PIN unit. For example, the PEGC with the location closest to the PIN unit and that can meet the KPI requirements of the PIN unit can be selected. Similarly, the PEMC can also select one or more alternative PEGCs to which the PIN unit will be assigned. When assigning alternative PEGCs, the PEMC can take into account the (multiple) expected locations of the PIN unit and configure the (multiple) alternative PEGCs that are closest to these expected locations and that can also meet the KPI requirements of the PIN unit.

[0154] In step 4, the PEMC can respond to PINE-1. The PEMC can include the assigned PEGC in the join response. For example, the PEMC can assign default PEGC-A based on the current location A of PINE-1 and assign alternative PEGC-B based on the expected location of PINE-1. In addition to the identifier and contact information for the PEGC, the PEMC can also include location information. This location information can subsequently be used by PINE-1 when determining which PEGC to use (e.g., comparing the PEGC location with the PINE-1 location).

[0155] In step 5, when PINE-1 is at location A (e.g., room 1 or floor 1 in a residence or building), PEGC-A can be used to communicate with other PIN units. Although not shown in Figure 10 , when the location of PINE-1 changes, PINE-1 can update its current location information unit stored in PEMC. Based on this location information, PEMC can change the default PEGC to PEGC-A and the alternate PEGC to PEGC-B. PEMC can update PEGC-A and PEGC-B with this updated dynamic PIN profile information.

[0156] In step 6, when PINE-1 moves to location B (e.g., room 2 or floor 2 in a residence or building), it can switch to using the alternate PEGC-B to communicate with other PIN units.

[0157] Operations Based on PEGC Scheduling

[0158] A particular PEGC may only be available to service communication requests from PIN units during a specific scheduled time window (e.g., between the hours of 8 pm and 8 am). For these types of usage scenarios, it may be necessary to have the PIN units make a transition between using one or more alternate PEGCs and the default PEGC based on the availability scheduling of each PEGC. Alternatively, the PIN unit can be configured to use one PEGC (e.g., PEGC-A) during a specific schedule period (e.g., 8 am to 8 pm) and another PEGC (e.g., PEGC-B) during a different schedule period (e.g., 8 pm to 8 am). There can also be different alternate PEGCs for each schedule. Figure 11 An example of this is shown.

[0159] In Figure 11 step 1, PEMC can request authorization for PIN creation from the PIN server, which can grant the request and provide PIN profile information to PEMC, such as but not limited to the information defined in Table 1.

[0160] In step 2, the PEMC can establish a PIN and determine PEGCs with different availability schedules (e.g., time windows). The different schedules can be the result of factors such as the schedules supported by the PEGCs themselves, the scheduling requirements of the PIN units (and their application clients) assigned to the PEGCs, and / or the scheduling requirements configured by the PIN manager or network operator. The PEMC can determine which PIN units will be assigned the role of PEGC by analyzing various information provided in the PIN client profiles of the PIN units that have joined the PIN. For example, the PEMC can consider the PEGC schedules supported by the PIN units with PEGC capabilities and the application client scheduling requirements of the various PIN units within the PIN. By doing so, the PEMC can ensure that the overall scheduling of the PEGCs is coordinated such that at least one default PEGC or standby PEGC is always available or at least available during the communication time windows of the PIN units it schedules.

[0161] In step 3, PINE-1 joins the PIN and can send a join request to the PEMC. Within this request, PINE-1 can include a PIN client profile. Information such as, but not limited to, the information defined in Table 3 can be included within this profile. For example, PINE-1 can provide one or more schedules for one or more application clients of the PIN unit. Based on this scheduling information, the PEMC can select the optimal default PEGC to be assigned to the PIN unit. For example, a PEGC with an availability schedule that completely overlaps the schedule of the PIN unit can be selected. If no single PEGC with a schedule that completely overlaps the schedule of the PIN unit is found, the PEMC can alternatively assign a default PEGC with the most schedule overlap and one or more standby PEGCs that overlap with any remaining time windows not covered by the default PEGC. Or, the PEMC can adjust the schedules of one or more PEGCs such that they completely overlap the schedule of the PIN unit.

[0162] In step 4, the PEMC can respond to PINE-1. The PEMC can include the assigned PEGC in the join response. For example, the PEMC can assign a default PEGC-A that covers a portion of the PINE-1 schedule and a standby PEGC-B that covers the remaining portion of the PINE-1 schedule. In addition to the identifier and contact information for the PEGC, the PEMC can also include PEGC scheduling information. This scheduling information can subsequently be used by PINE-1 when determining which PEGC to use (e.g., comparing the PEGC schedule with the PINE-1 schedule).

[0163] In step 5, when PINE-1 communicates during a time period that overlaps with the scheduling of default PEGC-A, PEGC-A can be used to communicate with other PIN units.

[0164] In step 6, when PINE-1 communicates during a time period that overlaps with the scheduling of PEGC-B, it can be switched to use the standby PEGC-B to communicate with other PIN units.

[0165] Graphical User Interface

[0166] The PIN manager can use the GUI to configure policies for the PIN server and / or PEMC that can be used to determine the need for multiple PEGCs within the PIN. Some examples are shown in Figure 12 below.

[0167] The UI can support the configuration of the PIN client profile on a PIN device (e.g., UE). The UI can be used by a user or a manager. The UI can support the configuration of application client-centric settings such as application client KPIs, scheduling, expected location, etc. The UI can also support PIN client-centric configuration settings such as the supported PIN capabilities (e.g., PEMC, PEGC, both), the supported PEGC KPIs, etc.

[0168] Figure 14A An embodiment of an exemplary communication system 100 in which the methods and apparatuses described and claimed herein can be specifically implemented is shown. As shown, the exemplary communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which generally or collectively can be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, but it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is Figure 14A - 14Eis depicted as a handheld wireless communication device, but it should be understood that for the various use cases envisioned for 5G wireless communication, each WTRU can include or be embodied in any type of device or equipment configured to transmit and / or receive wireless signals. By way of example only, the device or equipment includes user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smart phone, laptop computer, tablet device, netbook, notebook computer, personal computer, wireless sensor, consumer electronic device, wearable device (such as a smart watch or smart clothing), medical or e-health device, robot, industrial equipment, drone, vehicle (such as a car, truck, train or plane), etc.

[0169] The communication system 100 may further include base stations 114a and 114b. Base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmit and Receive Points) 119a, 119b, and / or RSUs (Road Side Units) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. By way of example, the base stations 114a, 114b may be transceiver base stations (BTSs), Node Bs, eNodeBs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are depicted as single units, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0170] Base station 114a may be part of RAN 103 / 104 / 105, and RAN 103 / 104 / 105 may further include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, and RAN 103b / 104b / 105b may further include other base stations and / or network elements (not shown), such as BSCs, radio network controllers (RNCs), relay nodes, etc. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographical area, which may be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, e.g., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may thus utilize multiple transceivers for each sector of the cell.

[0171] Base station 114a may communicate with one or more of WTRUs 102a, 102b, 102c via air interfaces 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interfaces 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0172] Base station 114b may communicate with one or more of RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interfaces 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0173] RRH 118a, 118b, TRP 119a, 119b, and / or RSU 120a, 120b may communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, and the air interface 115c / 116c / 117c may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0174] WTRU 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with each other via air interface 115d / 116d / 117d (not shown in the figure), and the air interface 115d / 116d / 117d may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0175] More specifically, as mentioned previously, the communication system 100 may be a multi-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in RAN103 / 104 / 105 and WTRU 102a, 102b, 102c, or the RRH118a, 118b, TRP 119a, 119b, and RSU 120a, 120b in RAN 103b / 104b / 105b and WTRU 102c, 102d, 102e, and 102f may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), so that the air interfaces 115 / 116 / 117 or 115c / 116c / 117c can be established using Wideband CDMA (WCDMA) respectively. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0176] In certain embodiments, the base station 114a and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, the TRPs 119a, 119b and / or the RSUs 120a, 120b in the RANs 103b / 104b / 105b and the WTRUs 102c, 102d may implement radio technologies such as Evolved Universal Mobile Telecommunications System Terrestrial Radio Access (E-UTRA), so as to respectively establish the air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). In the future, the air interfaces 115 / 116 / 117 may implement 3GPP NR technologies. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communication, etc.).

[0177] In certain embodiments, the base station 114a in the RANs 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, the TRPs 119a, 119b and / or the RSUs 120a, 120b in the RANs 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0178] Figure 14A The base station 114c in... may be, for example, a wireless router, a home Node B, a home eNode B or an access point, and may utilize any suitable RAT to facilitate wireless connection within a local area, such as business premises, home, vehicle, campus, etc. In certain embodiments, the base station 114c and the WTRU 102e may implement radio technologies such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In certain embodiments, the base station 114c and the WTRU 102d may implement radio technologies such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. AsFigure 14A As shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0179] RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b may communicate with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. By way of example, the core network 106 / 107 / 109 may provide call control, billing services, location-based mobility services, prepaid calling, Internet connectivity, video distribution, etc., and / or implement high-level security functions such as user authentication.

[0180] Although not shown in Figure 14A it should be appreciated that RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b and / or the core network 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same or different radio access technologies (RATs) as RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b. By way of example, in addition to being connected to RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b that may utilize E-UTRA radio technology, the core network 106 / 107 / 109 may also communicate with another RAN (not shown) employing GSM radio technology.

[0181] The core network 106 / 107 / 109 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 may include a wired or wireless communication network owned and / or operated by other service providers. By way of example, the network 112 may include another core network connected to one or more RANs that may employ the same or different RATs as RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b.

[0182] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. By way of example, Figure 14A the WTRU 102g shown in may be configured to communicate with base station 114a and with base station 114c, where base station 114a may employ a cellular-based radio technology and base station 114c may employ IEEE 802 radio technology.

[0183] Figure 14B is a block diagram of an exemplary apparatus or device configured for wireless communication in accordance with the embodiments described herein, such as a WTRU 102. As Figure 14B shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive unit 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing units while remaining consistent with the embodiments. Additionally, the embodiments contemplate that base stations 114a and 114b and / or nodes that base stations 114a and 114b may represent (such as, among others, but not limited to, transceiver stations (BTSs), Node Bs, site controllers, access points (APs), home Node Bs, evolved home Node Bs (eNodeBs), home evolved Node Bs (HeNBs), home evolved Node B gateways, and proxy nodes) may include Figure 14B some or all of the units depicted and described herein.

[0184] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may implement signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, and the transceiver 120 may be coupled to the transmit / receive unit 122. Although Figure 14BThe processor 118 and the transceiver 120 are depicted as separate components, but it should be appreciated that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0185] The transmit / receive unit 122 can be configured to send signals to / from and receive signals from a base station (such as base station 114a) via the air interface 115 / 116 / 117. For example, in one embodiment, the transmit / receive unit 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive unit 122 can be a transmitter / detector configured to transmit and / or receive signals such as IR, UV, or visible light signals. In another embodiment, the transmit / receive unit 122 can be configured to transmit and receive both RF and optical signals. It should be appreciated that the transmit / receive unit 122 can be configured to transmit and / or receive any combination of wireless signals.

[0186] In addition, although the transmit / receive unit 122 is depicted as a single unit in Figure 7 Figure B, the WTRU 102 can include any number of transmit / receive units 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive units 122 (such as multiple antennas) for transmitting and receiving wireless signals via the air interface 115 / 116 / 117.

[0187] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive unit 122 and demodulate the signals received by the transmit / receive unit 122. As previously mentioned, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers such that the WTRU 102 can communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0188] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In an embodiment, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102 (such as located on a server or a home computer (not shown)).

[0189] The processor 118 may receive power from a power source 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell battery packs, solar cells, fuel cells, etc.

[0190] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. As a supplement or alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via an air interface 115 / 116 / 117, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0191] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripherals 138 may include various sensors, such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for taking photos or videos), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, etc.

[0192] The WTRU 102 may be embodied in other devices or apparatuses, such as sensors, consumer electronic devices, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes). The WTRU 102 may be connected to other components, modules or systems of such devices or apparatuses through one or more interconnect interfaces, such as the interconnect interfaces that may form one of the peripherals 138.

[0193] Figure 14C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As previously mentioned, the RAN 103 may communicate with the WTRU 102a, 102b and 102c via the air interface 115 using UTRA radio technology. The RAN 103 may also communicate with the core network 106. As Figure 7 shown in

[0194] As Figure 14C shown, the Node Bs 140a, 140b may communicate with the RNC 142a. In addition, the Node B 140c may communicate with the RNC 142b. The Node Bs 140a, 140b, 140c may communicate with the corresponding RNCs 142a, 142b via the Iub interface. The RNCs 142a, 142b may communicate with each other via the Iur interface. Each of the RNCs 142a, 142b may be configured to control the corresponding Node Bs 140a, 140b, 140c connected thereto. In addition, each of the RNCs 142a, 142b may be configured to implement or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0195] Figure 14CThe core network 106 shown may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing units is depicted as part of the core network 106, it should be appreciated that any of these units may be owned and / or operated by an entity other than the core network operator.

[0196] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices.

[0197] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-capable devices.

[0198] As previously mentioned, the core network 106 may also be connected to a network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0199] Figure 14D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As previously mentioned, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c via an air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the core network 107.

[0200] The RAN 104 may include eNode-Bs 160a, 160b, 160c, but it should be appreciated that, while remaining consistent with the embodiments, the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit and receive wireless signals to / from the WTRU 102a.

[0201] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. As Figure 14D shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0202] Figure 7 The core network 107 shown in D may include a Mobility Management Gateway (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the foregoing units is depicted as part of the core network 107, it should be appreciated that any of these units may be owned and / or operated by an entity other than the core network operator.

[0203] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide control plane functionality for handovers between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0204] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions such as anchoring the user plane during handovers between eNode-Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the context of the WTRUs 102a, 102b, and 102c, etc.

[0205] The serving gateway 164 may also be connected to a PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-capable devices.

[0206] The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to a circuit switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, and 102c and traditional landline communication devices. For example, the core network 107 may include or communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), which serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to a network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0207] Figure 14E is a system diagram of the RAN 105 and the core network 109 according to an embodiment.

[0208] The RAN 105 may be an Access Service Network (ASN) that communicates with the

[0209] WTRUs 102a, 102b, and 102c via an air interface 117 using IEEE 802.16 radio technology. As will be further discussed later, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0210] As Figure 14EAs shown, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182. However, it should be appreciated that, while remaining consistent with the embodiments, the RAN 105 may include any number of base stations and ASN gateways. The base stations 180a, 180b, 180c may be respectively associated with specific cells in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via an air interface 117. In certain embodiments, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to transmit and receive wireless signals to / from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, etc. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, etc.

[0211] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as the R1 reference point that implements the IEEE802.16 standard. Additionally, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as the R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0212] The communication link between each of the base stations 180a, 180b, and 180c may be defined as the R8 reference point, which includes a protocol for facilitating WTRU handover and data transfer between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as the R6 reference point. The R6 reference point may include a protocol for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0213] As Figure 14EAs shown, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined as the R3 reference point, and the R3 reference point can include, for example, protocols for facilitating data transmission and mobility management capabilities. The core network 109 can include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. Although each of the foregoing units is depicted as part of the core network 109, it should be appreciated that any of these units can be owned and / or operated by entities other than the core network operator.

[0214] The MIP-HA can be responsible for IP address management and can enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 can provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-capable devices. The AAA server 186 can be responsible for user authentication and support for user services. The gateway 188 can facilitate interoperability with other networks. For example, the gateway 188 can provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. In addition, the gateway 188 can provide the WTRUs 102a, 102b, 102c with access to the network 112, which can include other wired or wireless networks owned and / or operated by other service providers.

[0215] Although not shown in Figure 14E it should be appreciated that the RAN 105 can be connected to other ASNs and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and other ASNs can be defined as the R4 reference point, and the R4 reference point can include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and other ASNs. The communication link between the core network 109 and other core networks can be defined as the R5 reference point, and the R5 reference point can include protocols for facilitating interoperability between the home core network and the visited core network.

[0216] Described herein and in Figure 14A 、 Figure 14C 、 Figure 14D and Figure 14EThe core network entities shown are identified by the names given to these entities in certain existing 3GPP specifications, but it should be understood that in the future these entities and functions may be identified by other names, and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, in Figure 14A 、 Figure 14B 、 Figure 14C 、 Figure 14D and Figure 14E the specific network entities and functions described and shown are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or to be defined in the future.

[0217] Figure 14F is an exemplary computing system 90 in which one or more of the devices of the communication network shown in Figure 14A 、 Figure 14C 、 Figure 14D and Figure 14E can be embodied, such as specific nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may implement signal encoding, data processing, power control, input / output processing and / or any other function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor different from the main processor 91 and may implement additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate and process data related to the methods and apparatuses disclosed herein.

[0218] In operation, the processor 91 fetches, decodes, and executes instructions and transfers information to / from other resources via the system bus 80, the main data transfer path of the computing system. Such a system bus connects the components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0219] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that allows for the storage and retrieval of information. The ROM 93 typically includes stored data that cannot be easily modified. The data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide an address translation function to translate virtual addresses into physical addresses as instructions are executed. The memory controller 92 can also provide a memory protection function to isolate processes within the system and separate system processes from user processes. Thus, a program running in the first mode can only access the memory mapped by its own process virtual address space; it cannot access the memory within another process's virtual address space unless memory sharing between processes is set up.

[0220] In addition, the computing system 90 can include a peripheral controller 83 responsible for communicating instructions from the processor 91 to peripherals such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0221] The display 86 is controlled by a display controller 96 and is used to display visual output generated by the computing system 90. Such visual output can include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchpad. The display controller 96 includes the electronic components necessary to generate the video signal sent to the display 86.

[0222] In addition, the computing system 90 can include communication circuitry, such as a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as Figure 14A 、 Figure 14B 、 Figure 14C 、 Figure 14D and Figure 14ERAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112, such that computing system 90 can communicate with other nodes or functional entities of these networks. The communication circuitry, alone or in combination with processor 91, can be used to implement the sending and receiving steps of certain devices, nodes, or functional entities described herein.

[0223] Figure 14G An embodiment of an exemplary communication system 111 is shown in which the methods and apparatuses described and claimed herein may be embodied. As shown, the exemplary communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, a V2X server, and RSUs A and B, but it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One or several or all of WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cellular coverage boundary shown by the dashed line in the figure). WTRUs A, B, C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate via the Uu interface or the sidelink (PC5) interface.

[0224] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to implement and / or realize the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions, which are executed on a processor of a device or computing system configured for wireless and / or wired network communication. The computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented by any non-transitory (e.g., tangible or physical) information storage method or technology, but such computer-readable storage medium does not include signals. The computer-readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical disk storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.

Claims

1. A method, comprising: Receiving, by a Personal Internet of Things (PIN) unit with management capabilities (PEMC), a first PIN join request including first PIN client profile information from a first unit of the PIN, the first PIN client profile information indicating that the first PIN unit is capable of acting as a gateway in the PIN; Receiving, by the PEMC, a second PIN join request including second PIN client profile information from a second PIN unit, the second PIN client profile information indicating that the second PIN unit is capable of acting as a gateway in the PIN; Based on the first and second PIN client profile information, determining to configure the first and second PIN units as gateways of the PIN; Receiving a third PIN join request including third PIN client profile information from a third PIN unit; Based on the first, second, and third PIN client profile information, determining to assign the first PIN unit as the default gateway for the third PIN unit and the second PIN unit as the standby gateway for the third PIN unit; Sending a notification to the first PIN unit, the notification including information indicating that the first PIN unit acts as the default gateway for the third PIN unit; Sending a notification to the second PIN unit, the notification including information indicating that the second PIN unit acts as the standby gateway for the third PIN unit; And Sending a response to the third PIN unit, the response indicating that the first PIN unit acts as the default gateway and the second PIN unit acts as the standby gateway for transmitting messages between the third PIN unit and other units in the PIN.

2. The method according to claim 1, wherein The first and second PIN client profile information includes supported gateway key performance indicators (KPIs), and the third PIN client profile information includes application KPIs.

3. The method according to claim 2, wherein, Determining to configure the first PIN unit to act as the default gateway for the third PIN unit and the second PIN unit to act as the standby gateway for the third PIN unit is based on the gateway KPIs supported by the first and second PIN units and the application KPIs of the third PIN unit.

4. The method according to claim 1, wherein The first and second PIN client profile information includes supported gateway schedules, and the third PIN client profile information includes application schedules.

5. The method according to claim 4, wherein Determining to configure the first PIN unit to act as the default gateway for the third PIN unit and the second PIN unit to act as the standby gateway for the third PIN unit is based on the gateway schedules supported by the first and second PIN units and the application schedule of the third PIN unit.

6. The method according to claim 1, wherein The first, second, and third PIN client profile information respectively includes the location information of the first, second, and third PIN units.

7. The method according to claim 6, wherein, Determining to configure the first PIN unit to act as the default gateway for the third PIN unit and the second PIN unit to act as the standby gateway for the third PIN unit is based on the proximity of the third PIN unit to the first and second PIN units.

8. The method according to claim 1, further comprising: Detecting the expiration of a heartbeat timer for the first PIN unit; And Based on the expiration of the heartbeat timer of the first PIN unit, determine to configure the second PIN unit to act as the default gateway for the third PIN unit.

9. A device with management capabilities in a PIN, the device including one or more processors configured to perform the following steps: Receive a first PIN join request including first PIN client profile information from a first unit of the PIN, the first PIN client profile information indicating that the first PIN unit is capable of acting as a gateway in the PIN; Receive a second PIN join request including second PIN client profile information from a second unit of the PIN, the second PIN client profile information indicating that the second PIN unit is capable of acting as a gateway in the PIN; Based on the first and second PIN client profile information, determine to configure the first and second PIN units as gateways of the PIN; Receive a third PIN join request including third PIN client profile information from a third PIN unit; Based on the first, second, and third PIN client profile information, determine to assign the first PIN unit to act as the default gateway for the third PIN unit and assign the second PIN unit to act as the standby gateway for the third PIN unit; Send a notification to the first PIN unit, the notification including information indicating that the first PIN unit acts as the default gateway for the third PIN unit; Send a notification to the second PIN unit, the notification including information indicating that the second PIN unit acts as the standby gateway for the third PIN unit; And Send a response to the third PIN unit, the response indicating that the first PIN unit acts as the default gateway and the second PIN unit acts as the standby gateway for transmitting messages between the third PIN unit and other units in the PIN.

10. The apparatus according to claim 9, wherein, The first and second PIN client profile information includes supported gateway KPIs, and the third PIN client profile information includes application KPIs.

11. The device according to claim 10, wherein, The one or more processors are configured to: based on the gateway KPIs supported by the first and second PIN units and the application KPI of the third PIN unit, determine to configure the first PIN unit to act as the default gateway for the third PIN unit and configure the second PIN unit to act as the standby gateway for the third PIN unit.

12. The device according to claim 9, wherein, The first and second PIN client profile information includes supported gateway schedules, and the third PIN client profile information includes application schedules.

13. The apparatus according to claim 12, wherein, The one or more processors are configured to: based on the gateway schedules supported by the first and second PIN units and the application schedule of the third PIN unit, determine to configure the first PIN unit to act as the default gateway for the third PIN unit and configure the second PIN unit to act as the standby gateway for the third PIN unit.

14. The device according to claim 9, wherein, The first, second, and third PIN client profile information respectively includes the location information of the first, second, and third PIN units.

15. The apparatus according to claim 14, wherein, The one or more processors are configured to: determine to configure the first PIN unit to act as a default gateway for the third PIN unit and the second PIN unit to act as a standby gateway for the third PIN unit based on the proximity of the third PIN unit to the first and second PIN units.

16. The apparatus according to claim 9, wherein, The one or more processors are configured to: detect the expiration of a heartbeat timer for the first PIN unit; and determine to configure the second PIN unit to act as a default gateway for the third PIN unit based on the expiration of the heartbeat timer of the first PIN unit.

Images