Managing role changes in personal IoT networks

Abstract

A method for managing a personal IoT network (PIN) is described herein. In one aspect, a method may include determining, by a Personal IoT Network (PIN) Element Management Capability (PEMC) of the PIN, that a PIN Element Gateway Capability (PEGC) of the PIN is not within coverage of the PIN; the PEMC sends a request for enabling the PIN server to execute the PEGC role change to the PIN server; and receiving, by the PEMC and from the PIN server, a notification that a PIN element (PINE) of the PIN is selected to perform the PEGC function for the PIN.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 352,316, filed on June 15, 2022, and entitled “Managing Role Changes in Personal IoT Networks,” the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0003] IoT devices are becoming ubiquitous as more companies launch new products in different market sectors and consumers adopt IoT technology for home and personal use. Devices such as devices in smart homes (e.g., large and small appliances, lighting and switches, security cameras, motion and water detectors, electric meter readers, door locks and garage door openers) and personal wearables (such as AV / VR glasses, earphones and headphones, medical and health sensors) are beginning to be widely adopted by consumers due to their practicality and convenience. 3GPP has recognized the booming market opportunity and initiated various efforts within the standards organization to support the creation of Personal IoT Networks (PINs), which connect IoT devices together to communicate within and outside the PIN.

[0004] One such effort is being undertaken in the 3GPP SA6 working group, where an application enabler layer is defined to specify application layer APIs to help companies quickly and easily incorporate 3GPP technologies into their products. SA6 studies have begun defining application enabler functionality to support personal IoT network applications called PINAPPs. The results of this study are documented in 3GPPTR23.700-78.

[0005] Figure 1 The proposed PINAPP architecture defined in 3GPP TR 23.700-78 is shown. The architecture defines a PINAPP application enabler layer for managing personal IoT networks. The network operator deploys a PIN server in the data network to supply configuration information to the PINAPP client on the UE and authorize the creation of a PIN. The PIN element with management capabilities (PEMC) and the PIN element with gateway capabilities (PEGC) are responsible for PIN management and traffic routing of the PIN, respectively, while the PIN element (PINE) is an IoT device that is a member of the PIN. Within a PIN element, there can be one PIN client and each PIN client has one or more application clients.

[0006] The PIN element is an IoT device that can have a SIM card and an associated 3GPP subscription, or the PIN element can be a 3GPP device without a SIM card. In addition, the PIN element can be a non-3GPP device that operates using different access technologies (such as wifi and Bluetooth). For PIN elements without a SIM card and an associated 3GPP subscription, the device needs to be provisioned with a 3GPP-defined user identifier to use the 5G network and its services.

[0007] PIN communication can be carried out through operator-managed spectrum (such as spectrum used by Uu and PC5 interfaces) or non-operator-managed spectrum (such as wifi and Bluetooth). The Uu interface is defined as the radio interface between the UE and the RAN node or base station, and the PC5 interface is defined as the radio interface between two UEs. Both interfaces use access technologies defined by 3GPP.

[0008] Before creating a PIN, the PEMC can obtain authorization from a PIN server managed by the operator. The PEMC can be controlled by an authorized administrator or user, such as a homeowner or a family member of the homeowner who wants to create a PIN at home. After authorization, the PEMC can be able to create and delete PINs and add or remove members to the PIN. The PEMC can also designate a PIN element as a PEGC to provide data traffic routing functionality for the PIN. Routing in this case can be for within a PIN, between PINs, and through 5GS or 5GS-PIN. Intra-PIN routing is between members of a PIN, inter-PIN routing is between members of two different PINs, and 5GS-PIN routing is between remote PIN members (e.g., UE) on a 5G network and members of a local PIN. Remote PIN members can be members of a local PIN or have been authorized by the PIN server to access a local PIN. In addition to routing intra-PIN traffic using PEGC, a PIN element can also communicate directly with another PIN element within a PIN if authorized. A PIN element that is a non-3GPP device and wants to join a PIN must be assigned a user identifier by the PEMC in order to communicate over a 5G network and use the services of a 5G network.

[0009] 3GPP TR 23.700-78 has identified several key issues to be addressed regarding the management and operation of PINs. An important consideration in creating a PIN is obtaining authorization from the PIN Server. After authorization, a PIN profile may be provided to the PEMC to assist the PEMC in managing the creation of the PIN. The currently proposed PIN profile only provides basic information about the members and construction of the PIN, such as contact information and identification of the PIN members. No management information is provided to assist the PEMC in the actual management aspects of the PIN operation.

[0010] Furthermore, PIN operation may be dynamic and the initial assignment of PEMC and PEGC functionality may change over time. For example, an authorized administrator may need to perform a software update of the PEMC or even a complete device upgrade. Similarly, the PEGC may leave the local area of ​​the PIN and routing functionality for PIN communications may be unavailable. Furthermore, the PEMC or PEGC may unexpectedly fail and cause disruption to the management of the PIN or traffic routing. Thus, these examples demonstrate that PIN role changes may be required to cope with dynamic changes in PIN operation. Summary of the invention

[0011] The present invention discloses a method for a PIN client acting as a PEMC, the method comprising: sending an authorization request for creating a personal IoT network (PIN) to a PIN server; receiving a response with authorization for creating the PIN, the response including a PIN profile, the PIN profile including information for managing the PIN, the management information including one or more of the following items: ID, PEMC and PEGC information, PIN element list, policy expiration, heartbeat timer, PIN location, PIN element ID list, role change configuration, role change order, PIN routing authorization, data traffic limit, subscription ID, maximum number of PINs, operator policy for PIN management, usage record collection, and refresh interval; receiving a PIN registration request from a PIN element to become a member of the PIN, the registration request including one or more of the following: PINE user type, PINE capabilities, member persistence, device identifier, device type and information, device life, battery level, sleep cycle, PINE location, and access type; sending a registration response to the PIN element, the registration response including one or more of the following: PIN element ID, PINE location, sleep cycle, heartbeat timer, and routing authorization information; and sending a PIN policy update request to a PIN server with updated PIN member information, the PIN policy update request including one or more information elements defined in Table 1 or Table 2; wherein the request can be triggered by adding one or more PIN members or the expiration of a refresh interval.

[0012] This document discloses a method for a PIN client located within the local coverage of a PIN, the method comprising: detecting an event in which PEMC or PEGC is unavailable in the PIN; changing the role of a PIN member, wherein the role change is to assign the role of PEMC or PEGC to another member, or to assume the role of PEMC or PEGC; if the policy requires, then performing a PIN policy update on the PIN server, wherein the update of the PIN policy includes changes to one or more of the following: PIN ID, PEMC or PEGC information, PIN element list, policy expiration, heartbeat timer, PIN location, PIN element ID list, role change configuration, role change sequence, PIN routing authorization, data traffic limit, subscription ID, maximum number of PINs, operator policy for PIN management, usage record collection, and refresh interval; and sending a notification of the role change to all members of the PIN.

[0013] The present invention discloses a method for a PIN client located outside a local area network of a PIN, the method comprising: detecting that a PEMC or PEGC in the PIN is unavailable; and sending a request to a PIN server to initiate a PEMC or PEGC role change, wherein the request may include one or more of the following: a UE ID, a PIN ID, an indication of a role change of the PEMC or PEGC for the PIN, a role change token for authorizing the role change, a PINE identifier selected for the new role, and a reason for the role change.

[0014] The present invention discloses a method for a PIN server, wherein the PIN server is configured with a PIN profile, wherein the PIN profile includes one or more of the following items: PIN ID, PEMC and PEGC information, PIN element list, policy expiration, heartbeat timer, PIN location, PIN element ID list, role change configuration, role change sequence, PIN routing authorization, data traffic limit, subscription ID, maximum number of PINs, operator policy for PIN management, usage record collection, and refresh interval; receive a request from PEMC for authorization to create a PIN, the request including one or more of the following: UE identifier, subscription information for authorization to create a PIN, the number of PINs requested for authorization, and the number of PIN members requested for authorization; send a response for authorization to create a PIN, the response including information for PEMC to create and manage one or more PINs, the information including information from a PIN profile and management configuration information, the management configuration information including one or more of the following: PIN ID, PEMC or PEGC information, PIN element list, policy expiration, heartbeat timer, PIN location, PIN element ID list, role change configuration, role change sequence, PIN routing authorization, data traffic limit, subscription ID, maximum number of PINs, operator policy for PIN management, usage record collection, and refresh interval; receive a PIN policy update, wherein the information in the PIN profile is updated with information of PIN management performed by the PEMC.

[0015] This article discloses a method for a PIN server, which method: receives a PIN modification request to perform a PIN role change, the request including one or more of the following: PIN ID, PEMC ID, PEGC ID, PIN member ID that plays a role in a new role of PEMC or PEGC; sends a response to the PIN modification request and includes information including one or more of the following: PIN ID, PEMC or PEGC information, PIN element list, policy expiration, heartbeat timer, PIN location, PIN element ID list, role change configuration, role change sequence, PIN routing authorization, data traffic limit, subscription ID, maximum number of PINs, operator PIN management policy, usage record collection and refresh interval. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 Describes the Personal IoT Network Application (Enabler Layer) (PINAPP) architecture in 3GPP SA6 Working Group;

[0017] Figure 2 Describes the process for PIN authorization and registration;

[0018] Figure 3Describes a process for PIN role change involving PEMC;

[0019] Figure 4 Describes a process for PIN role changes involving PEGC;

[0020] Figure 5 Another process for PIN role change involving PEGC is depicted;

[0021] Figure 6 Describes the process for UE-requested PIN role change;

[0022] Figure 7 Describes a process for PIN role change delegation;

[0023] Figure 8 and Fig. 9 depicts a graphical user interface (GUI) for managing role changes in a PIN;

[0024] Fig. 10A An example communication system is depicted in which the methods and apparatus described and claimed herein may be an aspect thereof;

[0025] Fig. 10B depicts a block diagram of an example apparatus or device configured for wireless communication;

[0026] Fig. 10C A system diagram depicting an example radio access network (RAN) and core network;

[0027] Fig. 10D depicts another example RAN and core network system diagram;

[0028] Fig.10E depicts another example RAN and core network system diagram;

[0029] Fig.10F depicts a block diagram of an example computing system; and

[0030] Figure 10G A block diagram of another example communication system is depicted. DETAILED DESCRIPTION

[0031] With the popularity of IoT devices in homes and personal wearable devices, the management of personal IoT networks (PINs) becomes an important aspect to consider. Users (such as homeowners) can deploy many PINs throughout the home and can have additional PINs in the form of personal wearable devices. Connecting a PIN to a cellular network provides users with ubiquitous coverage and access, but it also introduces complex management scenarios. The roles of a PIN element with management capabilities (PEMC) and a PIN element with gateway capabilities (PEGC) can change during the life cycle of a PIN, so PIN role changes can be addressed. The method described in this article addresses different PIN role change scenarios. PIN role changes can be initiated by a requesting entity, or can be operated autonomously based on a configuration. In addition, it is proposed to add a management information element to the PIN profile to allow PEMC and PEGC to better manage PINs.

[0032] The PEMC may obtain authorization from a PIN server to be able to create a PIN locally. The PIN server is an operator-owned entity configured to provide PIN profiles for the operation of managing PINs to the PEMC or PEGC. Figure 2 The process of the PEMC obtaining authorization from the PIN server for creating a PIN and the PIN server providing the PIN profile to the PEMC to manage the PIN is shown. In addition, the process of PIN registration and PIN server and PIN discovery are also described. Note that the steps in the figure can be performed in an order other than the order shown in the figure.

[0033] In step 1, a PIN policy is configured on the PIN server. The PIN policy may contain information as shown in Table 1. The table is based on the PIN profile table in TR23.700-78 and shows the proposed enhancements to the PIN profile in bold text. Note that from the perspective of PIN operation, the terms "PIN policy" and "PIN profile" may refer to information elements that a PEMC or PEGC is supplied with and used to manage (one or more) PINs. The terms "PIN profile" and "PIN policy" may be used interchangeably below. The label "Y" in Table 1 indicates that the entity in that column may (optionally) maintain the information in that row, while the label "N" indicates that the entity in that column may not maintain the information in that row. Note that the label "Y" refers to the availability of the information element to the corresponding PIN entity and does not indicate that the information element is mandatory.

[0034] Table 1 - PIN Profile Enhancements

[0035]

[0036]

[0037]

[0038]

[0039] A policy expiration time may be provided to indicate an authorized period of time in which the PIN may operate. This expiration timer controls the use of operator radio resources within the PIN and may be updated by the PEMC with a PIN policy update request. A heartbeat timer may also be supplied by the PIN server to request the PEMC or PEGC to periodically report on the status of the PIN. The PIN server may use these updates to detect problems with the operation of the PIN and potentially fix the problem, for example by performing a PIN role change.

[0040] The PIN location can be reported by the PEMC to the PIN server to indicate the operating location of the PIN, whether using GPS coordinates, street address or other location information. Alternatively, the PIN location can also be provided by an authorized administrator or PIN server. The PEMC can be supplied with a list of PINE IDs, where the PIN server provides a list of identifiers that the PEMC can assign to PIN elements that do not have a SIM card. Typically, these can be non-3GPP IoT devices that primarily communicate using alternative radio access technologies (such as wifi and Bluetooth). PIN elements are required to have an identifier assigned by the operator in order to use radio resources and services owned by the operator. The PEMC can assign a PINE ID to a PIN element from a pool of PINEIDs that have been authorized by the PIN server during PIN registration. Both location information and the PINE ID can be used as part of PIN discovery, for example, by a family member of an authorized administrator to discover and register with the PIN.

[0041] If the PIN server authorizes the PEMC to perform a local PIN role change in certain circumstances, a role change capability information element is provided to the PEMC. For example, if the PEGC is unavailable due to low battery levels or mobility beyond the local PIN area, the PEMC may be able to initiate a PIN role change process to assign a new PEGC so that PIN communications can continue. Similarly, an authorized administrator may want to perform a software or device upgrade of the PEMC and may initiate a PIN role change to assign a new PEMC to manage the PIN. The operator may also include a PIN profile update timer as part of the role change configuration, where the PEMC of the PIN may report the role change to the PIN server within the indicated timer value and provide a specified role change token to authenticate the role change. The PEMC that reports the PIN role change may be the original PEMC of the PIN or a new PEMC of the PIN. In the event that the role change is not reported within the indicated timer value, the PIN server may intervene and initiate a PIN role change.

[0042] PIN communications can use radio resources owned by the operator, and therefore, the PIN profile may include PIN routing authorization for the entire PIN or for each PIN element individually. PIN routing authorization can generally be specified for intra-PIN, inter-PIN, and 5GS-PIN. Intra-PIN routing is used for PIN communications within members of a specific PIN, while inter-PIN routing refers to local PIN communications between members of one PIN and another member of a different PIN. 5GS-PIN routing refers to the situation where PIN communications are routed externally to another entity through a 5G network. Another entity may be a UE authorized to communicate with PIN members, or it may be a member of a remote PIN. The operator may also specify data traffic restrictions for PIN communications to prevent congestion of radio resources owned by the operator. PIN routing authorization may also be specified as routing rules that are more suitable for specific devices or traffic types. Routing rules may include allowed endpoints (such as application servers or data networks), locations (e.g., a certain address, autonomous region, city, country, etc., or tracking or registration areas) and time constraints, traffic types, communication schedules, communications with specific network entities, and the like.

[0043] In step 2, an authorized administrator (e.g., a homeowner who plans to deploy (one or more) PINs in a home) issues a request to the PIN server via the PEMC to obtain authorization to create a PIN. The PEMC may be an application client running on a UE or some other PIN device and may have discovered or been supplied with information to contact the PIN server. The request may include the UEID, subscription information authorizing the creation of the PIN, the number of PIN members and PINs requested to be authorized. The PIN server grants authorization to the PEMC and may provide configuration and PIN policy information for the PEMC to manage the PINs. The PIN policy may include information as shown in Table 1, and the configuration information may include information as shown in Table 2. Note that even though the information in Tables 1 and 2 is presented separately, the information may be combined to form a policy that the PEMC is supplied with and uses to manage (one or more) PINs.

[0044] Table 2-PIN management configuration information

[0045]

[0046]

[0047] The configuration information shown in Table 2 can be used by the PEMC as a general management policy that the PEMC applies to all PINs it manages, such as the subscription ID associated with each PIN and the maximum number of PINs that the PEMC can manage. In addition, the configuration information can include operator policies on how to interact with the PIN server and applicable reporting requirements. Alternatively, the configuration information shown in Table 2 can be specified on an individual PIN basis. In this case, the information can be merged into the PIN profile shown in Table 1.

[0048] In step 3, PIN discovery can be performed by devices near the PEMC. The PEMC can broadcast discovery information about the PIN to nearby devices. Other discovery processes can be performed, such as ProSe discovery, wifi discovery, Bluetooth pairing, QR code scanning, DNS-SD, mDNS, Bonjour, CORE resource directory, etc.

[0049] In step 4, the PIN element interested in joining the PIN can issue a registration request to the PEMC and include the UE or device ID, PINE user type, PINE capabilities, member consistency, device type and information, device capabilities, or other information, as found in the PIN element list information element of the PIN profile shown in Table 1. Note that the PIN element list is represented as an information element of the PIN profile in Table 1, but the information can be grouped separately into the PINE profile. PIN elements with management capabilities, gateway capabilities, or both can indicate this capability in the PINE capability information element. This information can be important for the PEMC when making PIN role change decisions. Device-specific information and other information (such as battery power and sleep cycles) can be provided to the PEMC to assist the PEMC in better managing the PIN elements. The PIN element can also request membership persistence during registration to ensure that the PIN element maintains membership even if the PIN element is no longer in the local PIN area. This feature can be useful for PIN elements such as mobile UEs that may frequently leave the local area of ​​the PIN (e.g., users who leave the home where the PIN is located). The PEMC may return a PIN element ID from the pool supplied by the PIN server, a heartbeat timer for the PIN element to maintain communication with the PEMC to ensure membership, one or more PIN routing authorizations that may be supplied to the PIN element to specify constraints on PIN data traffic, and other information from the PIN profile as shown in Table 1.

[0050] In step 5, after adding the member to the PIN, the PEMC may perform a PIN policy update to the PIN server with the updated information about the PIN membership. The PEMC may wait until the refresh interval expires before providing the update and any usage records of the PIN traffic. The PIN policy update may satisfy the heartbeat requirement and reset the timer accordingly to minimize signaling between the PEMC and the PIN server. The PIN policy update process may also be used to update the PIN location in the event that the PIN moves (e.g., when the PIN member is a personal wearable device), update the PIN profile, request more PINE IDs, or request new PIN routing authorization. In addition, the PEMC may also perform a PIN policy update to the PEGC and / or (one or more) PINEs.

[0051] At step 6, a UE that is not part of the PIN may perform a PIN server discovery with the 5GS. The UE may have been provisioned with the network slice and data network name information for discovery and creation of a PDU session to communicate with the PIN server. After discovering the PIN server, the UE may make a PIN discovery request to find the PIN. The user of the UE may be a family member of the authorized administrator and may be provided with certain information about the PIN, such as PIN ID, PIN location, etc.

[0052] In step 7, the UE may make a registration request to the PEMC through the PEGC. The UE may include information in the Pin Element List information element from the PIN profile shown in Table 1. The UE may specify that it is an authorized user of the PIN for the PINE user type and may even request membership persistence. Other user types may be authorized administrators, guest users, PIN service providers and services provided, etc.

[0053] In step 8, after registration, if the UE is authorized, it can access PINE1 through PEGC.

[0054] Certain information in the PIN profile shown in Table 1 may be supplied to members of the PIN during PIN registration or policy updates, such as a PIN element list or a policy expiration information element. The columns labeled PIN Server, PEMC, PEGC, and PINE in Table 1 may indicate information from the PIN profile that each corresponding entity is supplied and maintains during the duration of PIN membership. Common information may be periodically synchronized by performing PIN policy updates based on a heartbeat timer or some operator-controlled policy.

[0055] During the operation of the PIN, certain events may require the PEMC, PEGC, or even the PIN Server to perform a PIN role change procedure, in which a PIN element is identified and assigned a new role of the PEMC or PEGC. Some events that may require a PIN role change are failure of the PEMC or PEGC, low battery conditions, software or operating system updates, device upgrades, mobility of PIN elements, etc. Figure 3 An example of a PIN role change involving a PEMC is shown. In this example, an authorized administrator plans to perform maintenance on the PEMC and initiates a PIN role change to transfer the PEMC functionality to another PIN member. Note that the steps in the figure can be performed in an order other than that shown in the figure.

[0056] In step 1, a local PIN may be created, where PEMC, PEGC, and two PIN elements PINE1 and PINE2 exist.

[0057] In step 2, an authorized administrator may schedule maintenance operations for the PEMC, for example, to perform a software update or upgrade the PEMC to a newer model, and configure the PEMC to initiate a PIN role change. This configuration may be performed via a management API supported by the PEMC.

[0058] In step 3, the PEMC or an authorized administrator may determine that PINE2 should be selected to serve as the new PEMC for the PIN. The PEMC sends a PIN role change request to PINE2 to assign the PEMC role to PINE2. The request may include the PIN profile information currently managed by the PEMC, and the possible duration that PINE2 should serve as the new PEMC. The request may also include a token that PINE2 may use to authenticate and authorize the PEMC to perform the role change to PINE2. If PINE2 accepts the role change to the PEMC, then PINE2 may send a response to the PEMC indicating acceptance of the role change.

[0059] In step 4, based on operator policy or other information in the PIN profile, the PEMC may perform a PIN policy update to inform the operator that PINE2 will serve as the new PEMC for the PIN. The PIN policy update may be a PIN modification request, and the request may include the PIN ID, PEMC ID, PEGC ID, the ID of the PIN member that may serve as the new PEMC, the duration that PINE2 will serve as the PEMC, and the role change token (if the token is provided in the PIN profile). The request may also include other information such as shown in Tables 1 and 2. Alternatively, PINE2 may also send a PIN profile update request and a role change token that may be used for authentication and authorization purposes for the role change. Note that in some cases, if the operator policy requires the PEMC to obtain authorization for the role change before assigning the role change to PINE2, then step 4 may be performed before step 3. In that case, the PIN server may provide a new role change token in the response to the request, and the PEMC may use the token to request PEMC functionality from PINE2 after the maintenance operation is completed. Operator policy may mandate PEMC autonomous management capabilities, where the PEMC is able to perform temporary local role changes without performing a PIN policy update, such as in this example.

[0060] The PEMC or PINE2 may send a PIN role change notification to the members of the PIN at step 5. The notification may include an indication of the role change, contact information for PINE2 to receive future PIN management requests, the duration that PINE2 will serve as the new PEMC, and other information from the PIN profile.

[0061] In step 6, if or when the original PEMC is able to resume management of the PIN, the PEMC may issue a request for a PIN role change to PINE2. Alternatively, PINE2 may issue this request when PINE2 detects that the original PEMC is back online, since PINE2 is the current PEMC. The request may include a PIN role change token so that PINE2 can authenticate and authorize the role change operation. If the role change request is granted, then PINE2 may return in a response the current state of the PIN profile and any other information it uses to manage the PIN.

[0062] In step 7 , PEMC or PINE2 may send a PIN role change notification to all members of the PIN, and may include the same information as in step 5 .

[0063] In the previous example, the PIN role change involves the PEMC, where the role change is required due to a software update or device upgrade of an existing PEMC. There may be other events that trigger a PIN role change involving a PEGC. Figure 4 One such example is shown, where a UE acting as a PEGC leaves the local PIN area and is no longer able to provide traffic routing for the PIN. The PEMC detects the absence of the UE (perhaps through a heartbeat mechanism or through a notification from another PIN element that traffic routing is unavailable) and proceeds to request the PIN server to perform a role change to select a new PEGC. Note that the steps in the figure may be performed in an order other than that shown in the figure.

[0064] In step 1, a local PIN may be created with PINE1, PINE2, PEMC and the UE acting as a PEGC.

[0065] In step 2, the UE may leave the local PIN area, for example, the owner of the UE leaves home.

[0066] At step 3, the PEMC may detect that the UE has left the local coverage of the PIN and no longer provide PEGC functionality. The PEMC may perform this detection based on regular heartbeat communications with the UE. Alternatively, PINE1 or PINE2 may have informed the PEMC that PIN traffic routing is unavailable.

[0067] In step 4, the PEMC may send a PIN policy update request to the PIN server to perform PIN modification for the PEGC role change. The PEMC may include in the request the PINID, the PEMC ID, the UE's PEGC ID, the ID of the PIN member that can be used as the new PEGC, and other information shown in Table 1. The PIN server may select a PIN member provided by the PEMC or another PIN member as the new PEGC for the PIN. The PIN server responds with the status of the request and may provide an update to the PIN profile maintained by the PEMC, for example, an identifier of the new PEGC. The PIN server may instruct the PEMC to notify other members of the PIN of the new PEGC.

[0068] In step 5, the PIN server may send PINE2 management information from Table 1 and Table 2 so that PINE2 assumes the new role. The PIN server may provide traffic routing authority to PINE2 so that PINE2 routes traffic remotely, for example, outside the PIN.

[0069] The PEMC may send PIN role change notification(s) to other members of the PIN to indicate the new PEGC for the PIN at step 6. The notification may include an indication of the role change, contact information for PINE2 to receive future PIN traffic routing requests, and other information from the PIN profile.

[0070] Figure 4The process in shows a scenario where the PEMC is able to request a PEGC role change from the PIN server after detecting that the UE has left the local area of ​​the PIN. Another scenario may be that the PEMC may not be able to request a role change directly from the PIN server because of Internet connectivity issues with the home network or a temporary outage with the PIN server. In this scenario, and if the PEMC is authorized to make local PIN management decisions (e.g., as indicated by a role change configuration information element or operator policy authorization), the PEMC can assign a new PEGC role to the PIN member and then inform the PIN server when connectivity is restored. Figure 5 An alternative scenario is shown where the PEMC performs a local role change for the PEGC and then informs the PIN server of the role change over the 5G network. This scenario provides a degree of autonomy for either the administrator or the PEMC to perform local PIN management if authorized by the PIN server. Figure 5 In the scenario of , local PIN management can enable restoration of connectivity for members of the PIN by using network resources of the 5G network (i.e., 3GPP access network).

[0071] In step 1, a local PIN may be created with PINE1, PINE2, PEMC and the UE acting as a PEGC.

[0072] In step 2, the UE may leave the local PIN area, for example, the owner of the UE leaves home.

[0073] At step 3, the PEMC may detect that the UE has left the local coverage of the PIN and no longer provide PEGC functionality. The PEMC may perform this detection based on regular heartbeat communications with the UE. Alternatively, PINE1 or PINE2 may have informed the PEMC that PIN traffic routing is unavailable.

[0074] At step 4, the PEMC may send a PIN policy update request to the PIN server to perform a PIN modification for the PEGC role change. This request may not be completed due to connectivity issues with the home network (e.g., Internet connectivity is interrupted or unavailable). Alternatively, the PIN server may be unavailable or experiencing a temporary outage.

[0075] In step 5, if the PEMC is authorized to perform a local role change, then the PEMC may inform PINE2 that it will serve as the new PEGC and may provide appropriate PIN profile information to PINE2, such as PIN routing authorization and data traffic restrictions. The PIN routing authorization may be restricted so that PINE2 can only route traffic from the PEMC, for example, performing a PIN policy update to the PIN server. The PEMC may have used information from the PIN profile to determine which PIN elements in the PIN may serve as the new PEGC. The PEMC may also use the PINE capability enhancements previously proposed in Table 1 to select a new PEGC. PINE2 may need to establish a PDU session with the 5GS to support remote PIN traffic routing.

[0076] After the new PEGC is assigned, the PEMC or the new PEGC may notify other members of the PIN of the role change, step 6. The notification may include an indication of the role change, contact information for PINE2 for receiving future PIN traffic routing requests, and other information from the PIN profile.

[0077] In step 7, if the PEMC is still unable to contact the PIN server, for example, home Internet connectivity is still unavailable, the PEMC may send a PIN policy update request to the PIN server via PINE2 using the PDU session previously created with the 5GS. PINE2 may establish a PDU session with the 5GS to provide network connectivity via the operator-managed spectrum. The request may include the PIN ID, PEMC ID, PEGC ID, an ID of a PIN member that may serve as the new PEGC, and other information as shown in Table 1. In response to the PIN policy update, the PIN server may return a PIN traffic authorization to enable PINE2 to route PIN data traffic through the 5GS.

[0078] In step 8, the PIN server may send PINE2 management information from Table 1 and Table 2 so that PINE2 assumes the new role. The PIN server may supply PINE2 with updated traffic routing authority so that PINE2 routes traffic remotely, for example, outside the PIN.

[0079] In step 9, the UE, which is now outside the local coverage of the PIN but is still a member of the PIN, can access the members of the PIN via 5GS. The UE may have requested membership persistence during PIN registration to enable the UE to leave the local area of ​​the PIN without being removed from the PIN. PIN elements without membership persistence can be automatically removed from the PIN when the PEMC detects that the PIN element no longer responds to PIN communications. The UE may have been provisioned with network slice and data network name information to create a PDU session for communicating with the PIN and a PIN server authorized to create the PIN. In addition, the UE can obtain PEGC contact information (e.g., URI, FQDN, IP address, etc.) and a list of PIN elements from the PIN profile it maintains to access any members of the PIN that it is authorized to access as a member of the PIN. Communications can be sent via 5GS to PINE2, which acts as a new PEGC, and finally to PINE1.

[0080] Figure 5 An alternative variation of the example may be that before the UE leaves the local PIN area, the UE may request a PIN role change from the PEMC or another PIN element. The UE may be able to determine from the PIN profile which PIN element in the PIN can serve as the new PEGC, or the UE may make a request to the PEMC and have the PEMC determine which PIN element can serve as the new PEGC. The UE may then transfer the PIN profile information it maintains to the new PEGC, including any PIN traffic routing information that the PIN server may have supplied.

[0081] Sometimes during PIN operation, a PIN element may fail without warning, either due to battery depletion or failure of one of the device's components. For these situations, especially if the failed PIN element is an element used as a PEMC or PEGC, the management and / or routing capabilities of the PIN may no longer be available. During these scenarios, intervention by an authorized administrator may be required to restore operation of the PIN. Figure 6 An example of this situation is shown. The authorized administrator is represented by a UE in the figure and is located outside the local area of ​​the PIN. The UE can be a PIN member with membership persistence. The UE may detect that either the PEMC or PEGC has failed, either through a dashboard application on the UE or the UE is unable to communicate with the PIN. The UE then issues a PIN modification request to the PIN server to perform a PIN role change for the failed PEMC or PEGC. Note that the steps in the figure may be performed in an order other than the order shown in the figure.

[0082] In step 1, a UE that may be an authorized administrator of a local PIN is outside the coverage of the local PIN. The UE may still be a member of the PIN and detect that there is a problem with the operation of the PEMC or PEGC of the PIN. The UE may have application layer information (e.g., from an application dashboard on the UE) indicating that the PEMC is not available or the PEGC is not routing the PIN traffic to the 5GS or other PINs in the home.

[0083] In step 2, using the PIN profile information stored locally on the UE, the UE may issue a PIN modification request to a PIN server that is authorized to create a PIN. The UE may include in the request the UE ID, PIN ID, an indication of the role change for the PIN or the PEMC or PEGC, a role change token for authorizing the role change, the PINE identifier selected by the UE for the new role, the reason for the role change, etc. The UE may make the request using the services of the 5G network or using PINAAP application layer traffic.

[0084] In step 3, the PIN server may process the request, including authentication and authorization of the UE if necessary, and may evaluate the provided token to ensure that the role change is authorized. The PIN server may use the information of the associated PIN ID in the PIN profile and the local operator policy to determine whether the UE is authorized to select a PINE for the new role, whether the selected PINE is capable but still a new role, whether to override the UE selected PINE, what management information is required for the role change, PIN routing authorization, etc.

[0085] In step 4, after the PIN server processes the request and makes a determination that the role change is allowed, the PIN server may send a PIN role change request to the PEMC, PEGC, or a PIN element that may be capable of assuming the role of the PEMC or PEGC. The request may include the PINID, the purpose of the modification request, or the assignment of the role change of the PEMC or PEGC, the PINE ID of the PINE assigned to the new role, and other information from the PIN profile. The PEMC, PEGC, or PIN element may return a response to the PIN server indicating acceptance of the role change.

[0086] In step 5, the PIN server may send management information of the new role to the selected PIN element, and may include appropriate management or traffic routing information from the PIN profile in the request information so that the PIN element starts managing the PIN or enabling traffic routing for the PIN. The PIN profile may include the information listed in Table 1 and Table 2. Note that steps 4 and 5 may be combined into one step.

[0087] The PIN server may return a response to the UE of the status of the PIN modification request in step 6. The response may include information such as the information listed in Table 1 that is applied to the role change, for example, management or PIN traffic routing information.

[0088] In step 7, the new PEMC or PEGC may send notification(s) to other members of the PIN indicating the role change. For the PEMC's role change, other PINEs may make management requests to refresh or delete registrations with the PIN and for the PEGC's role change, and other PINEs may make traffic routing requests for PIN traffic. The notification message may be broadcast, multicast, or unicast to other members of the PIN, and may include an indication of the role change, contact information for the PINE2 to receive future PIN management or traffic routing requests, and other information from the PIN profile.

[0089] In the previous examples, the PIN role change is initiated by the requesting entity, whether it is an authorized administrator, PEMC, PEGC or a user of the UE. A more proactive mechanism may be employed, where the PIN role change may be delegated and autonomously performed based on the configuration of the PIN profile. Using the role change configuration and role change sequence information elements of the PIN profile, a user or a PIN server may be able to configure autonomous PIN role changes upon detecting a triggering event, such as a PIN element failing to respond to PIN communications. Figure 7 An example of PIN role change delegation to enable autonomous PIN role change is shown. In this example, PEGC and PINE2 are PIN elements with gateway capabilities, and therefore, both are configured in a role change sequence to implement PEGC functionality. PEGC is configured as a default or first priority PIN element with gateway capabilities, and PINE2 is configured as a second priority PIN element with gateway capabilities. After a period of time, the PEGC fails and is unable to support PIN traffic routing. PINE2 detects that the PEGC is unavailable and may not receive a response from the PEGC to route PIN traffic to the 5GS. PINE2 checks whether the PIN role change sequence is available and autonomously performs the PIN role change. Note that the steps in the figure may be performed in an order other than the order shown in the figure.

[0090] In step 1, if the PIN server has been authorized for PIN role change delegation in the PIN profile, then the authorized administrator can configure the PEMC for PIN role change delegation. Alternatively, the PIN server can configure the PIN role change delegation function on the PEGC, PEMC, or any PIN element with corresponding management or gateway capabilities. In this example, the role change sequence is configured for PEGC and PINE2 for gateway capability delegation: PEGC is a higher priority PIN element, while PINE2 is a lower priority PIN element. If PINE2 detects that PEGC is unavailable, it can assume the PEGC functionality. Similarly, PEMC can also detect the unavailability of PEGC and notify PINE2 to act as PEGC. The PIN server can supply management or gateway information, which the PIN elements can use to manage or route PIN traffic, respectively.

[0091] In step 2, if the authorized administrator has configured PIN role change delegation for PEMC, then PEMC may configure PEGC and PINE2 with PIN role change delegation information (eg, role change sequence information element).

[0092] At step 3, after a period of time, the PEGC becomes unavailable, perhaps due to device or battery failure, or the PEGC is no longer within the coverage of the local PIN.

[0093] At step 4, PINE2 may detect that PEGC is no longer available in the PIN for routing traffic. PINE2 may have attempted to send a PIN communication to the 5GS but received no response from the PEGC.

[0094] In step 5, using the role change sequence information, PINE2 can determine that it next acts as a gateway capability PIN element and assumes the role of PEGC.

[0095] PINE2 may send a notification to members on the PIN indicating the role change at step 6. The notification message may be broadcast, multicast, or unicast to other members of the PIN and may include an indication of the role change, contact information of PINE2 for receiving future PIN traffic routing requests, and other information from the PIN profile.

[0096] In step 7, the PEMC may perform a PIN policy update to inform the PIN server that an autonomous PIN role change has occurred and that PINE2 is acting as the new PEGC. The PEMC may include in the request the PIN ID, PEMC ID, PEGC ID, the IDs of the PIN members that may act as the new PEGC, and other information as shown in Table 1.

[0097] In step 8, if the PIN server has not previously supplied PIN traffic routing information to PINE2 in step 1, the PIN server may send a PIN traffic routing authorization to PINE2. The PIN server may provide other management information as shown in Tables 1 and 2 that PINE2 may need in its new role.

[0098] Figure 7 One example of autonomous role change is shown and other examples can be envisioned. For example, the PEGC can detect that the PEMC has failed and determine which PINE to assign the role of the new PEMC to based on the role change sequence. If the PIN profile is configured as a PEMC, then the PEGC can even assume the role of the PEMC. Similarly, if the PEMC has obtained authorization from the PIN profile, then after detecting that the PEGC has failed, the PEMC can assume the role of the PEGC.

[0099] Figure 8 and Fig. 9 Two example graphical user interfaces that the UE may present to the user are shown to list the contents of a PIN profile as described in Table 1. The GUI may scroll vertically to display all information elements. Some information elements may be supplied by the PIN server (e.g., PIN ID, policy expiration, PIN server ID, PIN server endpoint, PINE ID list), while other information elements may be configured by an authorized administrator (e.g., PIN description, certain information in the PIN element list). The PIN client on the UE may also provide information to the PIN profile, such as the PEMC and PEGC endpoints and certain information in the PIN element list.

[0100] Example Communication System

[0101] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "8G". Development of the 3GPP NR standards is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backwards compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, UMB is expected to share a common design framework with sub-7GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0102] 3GPP has identified a variety of use cases that NR is expected to support, resulting in various user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other-entities communications. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car ecalls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases and others are contemplated herein.

[0103] Fig. 10AAn example communication system 100 is illustrated, of which the methods and apparatus described and claimed herein may be an aspect thereof. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (generally or collectively may be referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 108B, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it should be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Fig. 9 A-9E is depicted as a handheld wireless communication device, but it should be understood that for the various use cases expected for 8G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to transmit and / or receive wireless signals, and by way of example only, the device or apparatus includes a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, truck, train or airplane, etc.).

[0104] The communication system 100 may also include a base station 114a and a base station 114b. The 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 the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wire and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmission and reception points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRH 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 the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRP 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 the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSU 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 the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0105] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 108B, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In some cases, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may use multiple transceivers for each sector of the cell.

[0106] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0107] The base station 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b via a wired or air interface 118B / 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, cmWave, mmWave, etc.). The air interface 118B / 116b / 117b may be established using any suitable radio access technology (RAT).

[0108] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more WTRUs 102c, 102d, 102e, 102f via an air interface 118c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 118c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0109] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with each other via an air interface 118d / 116d / 117d (not shown), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 118d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0110] More specifically, as described above, the communication system 100 may be a multiple-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 the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 108B may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 118c / 116c / 117c, 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).

[0111] In some cases, the base station 114a and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b and the WTRUs 102c, 102d in the RAN 103b / 104b / 108B may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advance (LTE-A) to establish the air interface 115 / 116 / 117 or 118c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0112] In some cases, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, the TRPs 119a, 119b and / or the RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 108B may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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.

[0113] For example, Fig. 10AThe base station 114c in the example may be a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, etc. In some cases, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Fig. 10A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

[0114] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B may be in communication with a 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 the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).

[0115] Although not in Fig. 10A 108B and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

[0116] The core network 106 / 107 / 109 may also serve as a gateway for the 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 the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet Protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B or a different RAT.

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

[0118] Fig. 10B 1 is a block diagram of an example apparatus or device, such as, for example, WTRU 102, configured for wireless communication in accordance with various aspects described herein. Fig. 10B As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, 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 elements while remaining consistent with the example. Moreover, in some cases, the base stations 114a and 114b, and / or nodes of the base stations 114a and 114b may represent, for example, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and a proxy node, etc., and may include Fig. 10BPart of some or all of the elements described in and described herein.

[0119] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig. 10B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0120] The transmit / receive element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in some cases, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In some cases, the transmit / receive element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. In some cases, the transmit / receive element 122 may be configured to transmit and receive RF and light signals. It should be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0121] In addition, although the transmit / receive element 122 is Fig. 10B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some cases, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0122] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., such as UTRA and IEEE 802.11).

[0123] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a 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, the 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 a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, and the like. In some cases, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0124] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the 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 batteries, solar cells, fuel cells, etc.

[0125] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the 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 will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with the present invention.

[0126] 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 connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0127] The WTRU 102 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes), etc. The WTRU 102 may be connected to other components, modules or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 138).

[0128] Fig. 10C 1 is a system diagram of the RAN 103 and the core network 106. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. Fig. 10C As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with aspects of the present disclosure.

[0129] like Fig. 10C As shown in FIG. 1 , Node B 140a, 140b may communicate with RNC 142a. In addition, Node B 140c may communicate with RNC 142b. Node B 140a, 140b, 140c may communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b may communicate with each other via Iur interface. Each of RNC 142a, 142b may be configured to control the corresponding Node B 140a, 140b, 140c connected thereto. In addition, each of RNC 142a, 142b may be configured to perform 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.

[0130] Fig. 10CThe core network 106 shown in FIG. 1 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 elements is depicted as part of the core network 106, it should be appreciated that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0131] 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 circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0132] 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 packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0133] As described above, core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0134] Fig. 10D 1 is a system diagram of the RAN 104 and the core network 107. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0135] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with aspects of the present disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0136] 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, scheduling of users in the uplink and / or downlink, etc. Fig. 10D As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0137] Fig. 10D The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0138] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve 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 an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

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

[0140] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0141] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that 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, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0142] Fig.10E 1 is a system diagram of the RAN 105 and the core network 109. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As discussed further below, 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.

[0143] like Fig.10EAs shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with aspects of the present disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals 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, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0144] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, 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 an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

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

[0146] like Fig.10EAs shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes protocols for facilitating, for example, data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

[0148] Although not in Fig.10E 102a, 102b, 102c between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0149] This article describes and Fig. 9 A. Fig. 9 C. Fig. 9 D and Fig. 9The core network entities shown in E are identified by the names given to those entities in certain existing 3GPP specifications, but it should be recognized that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig. 9 A. Fig. 9 B. Fig. 9 C. Fig. 9 D and Fig. 9 The specific network entities and functionality described and illustrated in E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0150] Fig.10F is a block diagram of an exemplary computing system 90 in which Fig. 9 A. Fig. 9 C. Fig. 9 D and Fig. 9 E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110 or other networks 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, wherever or in any manner such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 perform 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, which may perform additional functions or assist the processor 91. Processor 91 and / or coprocessor 81 may receive, generate and process data related to the methods and apparatus disclosed herein.

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

[0152] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0153] In addition, the computing system 90 may include a peripheral device controller 83 that is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

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

[0155] Additionally, computing system 90 may include communications circuitry, such as a network adapter 97, which may be used to connect computing system 90 to an external communications network, such as a Fig. 9 A. Fig. 9 B. Fig. 9 C. Fig. 9 D and Fig. 9The processor 91 may be a processor that is configured to communicate with the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, or other networks 112) of the E to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuit system may be used to perform the transmission and reception steps of certain devices, nodes, or functional entities described herein.

[0156] Figure 10G An example communication system 111 is illustrated, of which the methods and apparatus described and claimed herein may be an aspect. As shown, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but it will be appreciated that the present disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E may be out of range of the network (e.g., outside the cell coverage boundary shown by the dashed lines in the figure). WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0157] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented 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 perform and / or implement 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 executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

[0158] definition

[0159] Definitions of abbreviations used in the text of this disclosure are provided below.

[0160] Additionally, note that the use of the term "PIN" in this disclosure refers to the PINAPP architecture and associated processes performed at the (one or more) application enabler layer and their corresponding information elements. Furthermore, the terms "PIN profile" and "PIN policy" may be used interchangeably to represent information elements used to manage the operation of a PIN. Finally, the figures in this disclosure may show steps with a bidirectional arrow between two entities to represent a request-response message pair.

[0161] 3GPP Third Generation Partnership Program 5GS 5G System AF App Features API Application Programming Interface AS Application Server FQDN Fully qualified domain name GUI Graphical User Interface IoT Internet of Things MNO Mobile Network Operators NEF Network exposure capabilities PCF Policy control function PEGC PIN element with gateway capability PEMC PIN element with management capabilities PIN Personal IoT Network PINAPP Personal IoT network applications (enabler layer) PINE PIN element ProSe Proximity-based services RAN Wireless Access Network SIM Subscriber Identity Module UE User Equipment VAL Vertical application layer

Claims

1. A method comprising: The PIN role change process is initiated by the Personal IoT Network (PIN) Element (PEMC) with management capabilities of the PIN; The PIN element (PINE) to which the PEMC functionality is to be transferred is determined by the PEMC; The PEMC sends a PIN role change request to the PINE; A PIN Policy Update Notification is sent by the PEMC instructing the PINE to perform PEMC functionality.

2. The method of claim 1, wherein PIN update notifications are sent to other PINEs of the PIN.

3. The method of claim 2, wherein the PIN update notification includes an indication of a PIN role change, contact information of the PINE, a duration that the PINE will perform PEMC functionality, profile information of the PINE, or a combination thereof.

4. The method of claim 1, wherein the PIN policy update notification includes identification information of the PIN, identification information of the PEMC, duration for the PINE to perform PEMC functionality, profile information of each PINE in the PIN, authentication information for the PEMC, or a combination thereof.

5. The method of claim 1, further comprising: A response is received at the PEMC from the PINE indicating acceptance of the PIN role change.

6. A method comprising: A PIN modification request is received by a personal IoT network (PIN) server from a wireless transmit / receive unit (WTRU); sending, by a PIN server and to a PIN element (PINE), a PIN role change request indicating a request to perform PIN element management capability (PEMC) or PIN element gateway capability (PEGC) functionality on the PINE; receiving, by the PIN server and from the requesting PINE, a message accepting the PIN role change request; as well as A response to the PIN modification request is sent by the PIN server to the WTRU, the response including updated PIN policy information according to the PIN role change.

7. The method of claim 6, wherein the PIN modification request includes the authorization credentials of the WTRU, identification information of the WTRU, identification information of the PIN, identification information of the PINE, identification of the PEMC or PEGC functionality, or a combination thereof.

8. The method of claim 6, wherein the sending of the PIN modification request is prompted by a failure of an operation of a PEMC or PEGC of the PIN.

9. The method of claim 6, further comprising: The PIN server sends a notification of the PIN role change of the PINE to other PINEs of the PIN.

10. The method of claim 6, wherein the WTRU is located outside of a local coverage area of ​​a PIN.

11. A method comprising: The PIN Element Gateway Capability (PEGC) of a PIN is determined by the PIN's Personal IoT Network (PIN) Element Management Capability (PEMC) to be outside the coverage of the PIN; The PEMC sends a request to the PIN server to execute the PEGC role change; as well as The PIN Element (PINE) received by the PEMC from the PIN Server is selected as a response to perform the PEGC function for the PIN.

12. The method of claim 11, wherein the response further comprises an indication that the PEMC notifies other PINEs of the PIN of the PEGC role change.

13. The method of claim 12, further comprising: The PEMC sends a notification of the PEGC role change to other PINEs in the PIN.

14. The method of claim 11, wherein the determination comprises a failure of the PEMC to receive periodic heartbeat communications from the PEGC.

15. The method of claim 11, wherein the PEGC resides on a wireless transmit / receive unit (WTRU).

Images