shows the logical PIN reference architecture.
A Personal IoT Network (PIN) in 5GC consists of one or more devices providing gateway/routing functionality known as the PIN Element with Gateway Capability (PEGC), and one or more devices providing PIN management functionality known as the PIN Element with Management Capability (PEMC) to manage the Personal IoT Network; and device(s) called the PIN Elements (PINE). A PINE can be a non-3GPP device.
The PIN can also have a PIN Application Server that includes an AF functionality. The AF can be deployed by mobile operator or by an authorized third party. When the AF is deployed by third party, the interworking with 5GS is performed via the NEF.
With PIN-DN communication, the PEMC and PEGC communicates with the PIN Application Server at the application layer over the user plane. The PEGC and PEMC can communicate with each other via PIN direct communication using 3GPP access (e.g. PC5) or non-3GPP access (e.g. WiFi, BT) or via PIN indirect communication using a PDU Session in the 5GS.
The general session management principles as described in clause 5.6
, the QoS model as defined in clause 5.7
and the User Plane management for 5GS as defined in clause 5.8
are applicable to PIN-DN communication and PIN-indirect communication.
If a PIN has multiple PEGC UEs, 5G VN group communication mechanisms can be used for PIN indirect communication (i.e. communication between PIN Elements belonging to the same PIN but served by different PEGC UEs). In this case a dedicated SMF set is used for managing the PIN related PDU Sessions from all the PEGCs of that PIN and the PDU session management principles for 5G VN-LAN-type services as specified in clause 5.29.3
are applicable. The user plane handling for 5G LAN-type services as specified in clause 5.29.4
are applicable with following differences:
For PIN indirect communication N19-based traffic forwarding is not used i.e. the PIN traffic is forwarded using:
N6-based traffic forwarding method, where the UL/DL traffic for the PIN communication is forwarded to/from the DN;
local switching as depicted in Figure P.2-1 below, following the principles of local switching of traffic for 5G VN LAN-type service.
The SMF configures the UPF(s) to apply N6-based traffic forwarding to route traffic between PDU Sessions of different PEGC UEs of a PIN as specified in clause 22.214.171.124
. The SMF can apply local switching as specified in clause 126.96.36.199
in order to enable UPF locally forward uplink stream from one PDU session of one PEGC UE of a PIN as downlink stream of PDU session of one or more PEGC UE(s) of the same PIN. For local switching of PIN traffic between PIN related PDU sessions from different PEGC UEs of a single PIN, based on the DNN and S-NSSAI that is used for the PDU session related to PIN, the SMF provides a Network Instance to the UPF in FAR and/or PDR via N4 Session Establishment/Modification procedures.
The protocol and format of satellite coverage availability information to be provisioned to the UE via PDU session or SMS is not defined in this release of the specification, but this annex provides some examples on the information that constitutes input to the source of satellite coverage availability information e.g. external server and the output it provides to the UE. Satellite coverage availability information can be indicated to the UE by indications corresponding to whether or not coverage is available for a specific NTN RAT Type for a particular location and time, where:
These indications can be Boolean "True" (e.g. coverage available) and "False" (coverage not available);
locations can correspond to grid points in a fixed array (e.g. rectangular, hexagonal);
Coverage availability times may occur at fixed periodic intervals; and
Coverage availability information is per RAT Type. The information provisioned to the UE can include coverage information on only one PLMN or multiple PLMNs.
If Satellite coverage availability information indicates coverage is available then additional information on whether PLMN is allowed to operate in that location can be provided to the UE.
In order for the source of satellite coverage availability information to provide accurate information to the UE, a UE might indicate for example the following information to a source of satellite coverage availability information (e.g. an external server):
Serving PLMN ID (if not already known or implied).
One or more satellite RAT Types (where satellite coverage availability information is then expected for these one or more RAT Types).
List of supported NTN frequency bands (if not implied by the particular RATs).
Present UE location (e.g. latitude and longitude) for a reference grid point (e.g. the most Southerly and then most Westerly grid point).
Type of Array (e.g. rectangular or hexagonal).
Minimum elevation angle.
Based on the above information provided by the UE, satellite coverage availability information could be delivered to the UE as a sequence of time durations for each grid point where each time duration includes an indication of coverage availability or unavailability one example of many alternatives as illustrated below for a particular grid point with N different durations:
Satellite coverage availability information at a given grid point = <N> <Binary 0 or 1><Duration 1> <Binary 0 or 1><Duration 2> . . . . <Binary 0 or 1><Duration N>
The above would be concatenated for all of the grid points to produce the satellite coverage availability information.
When SMS is used to deliver the satellite coverage availability information, the UE input and satellite coverage availability information output can be delivered in a series of concatenated SMS messages using possibly the same format.