https://wiki.gotopinion.info/wiki/api.php?action=feedcontributions&user=Paul&feedformat=atomGot Opinion Wiki - User contributions [en]2024-03-29T11:48:52ZUser contributionsMediaWiki 1.36.2https://wiki.gotopinion.info/wiki/index.php?title=My_102_232-3_notes&diff=3081My 102 232-3 notes2024-03-25T19:57:37Z<p>Paul: </p>
<hr />
<div>My notes on ETSI TS 102 232-3<br />
<br />
Version 3.13.1 (2024-01) was used as basis.<br />
<br />
== Internet Access Service (IAS) § 4.1 == <br />
<br />
Figure 1 Internet access diagram<br />
<br />
[[File:102-232-3 V3.8.1 Figure1.png|alt=102-232-3 V3.8.1 Figure 1 Internet access diagram|102-232-3 V3.8.1 Figure 1 Internet access diagram]]<br />
<br />
== Lawful Interception Requirements § 4.3 ==<br />
<br />
=== Result of interceptions § 4.3.2 ===<br />
<br />
The network operator, access provider or service provider shall provide Intercept Related Information (IRI), in relation to each target service:<br />
<ol type="a"><br />
<li>When an attempt is made to access the access network.</li><br />
<li>When an access to the access network is permitted.</li><br />
<li>When an access to the access network is not permitted.</li><br />
<li>On change of status (e.g. in the access network).</li><br />
<li>On change of location (this can be related or unrelated to the communication or at all times when the apparatus is switched on).</li><br />
</ol><br />
<br />
The IRI shall contain:<br />
<ol type="a"><br />
<li>Identities used by or associated with the target identity (e.g. dial-in calling line number and called line number, access server identity, Ethernet addresses, access device identifier).</li><br />
<li>Details of services used and their associated parameters.</li><br />
<li>Information relating to status.</li><br />
<li>Timestamps.</li><br />
</ol><br />
<br />
Content of Communication (CC) shall be provided for every IP datagram sent through the IAP's network that:<br />
<ol type="a"><br />
<li>Has the target's IP address as the IP source address.</li><br />
<li>Has the target's IP address as the IP destination address.</li><br />
</ol><br />
<br />
The CC Content of communication shall contain:<br />
<ol type="a"><br />
<li>A stream of octets for every captured datagram, containing a copy of the datagram from layer 3 upwards.</li><br />
</ol><br />
:NOTE: Due to the possibility of IP source address spoofing, the fact that an intercepted packet has the target's IP address as the IP source address does not guarantee that the packet was transmitted by the target; i.e. an intercept in place at the interface connected to the target may not include packets originating from other users spoofing the target's IP address and will not include packets from the actual target that contain a spoofed IP address.<br />
<br />
=== Intercept related information § 4.3.3 ===<br />
<br />
Intercept Related Information (IRI) shall be conveyed to the LEMF in messages, or IRI data records, respectively. Four types of IRI records are defined:<br />
<br />
# IRI-BEGIN record at the first event of a communication attempt, opening the IRI transaction.<br />
# IRI-END record at the end of a communication attempt, closing the IRI transaction.<br />
# IRI-CONTINUE record at any time during a communication attempt within the IRI transaction.<br />
# IRI-REPORT record used in general for non-communication related events.<br />
<br />
For a description of the use and purpose of the various IRI records refer to ETSI TS 102 232-1.<br />
<br />
== IRI events § 6.1 ==<br />
<br />
TODO: Insert Figure 6 state diagram for an Internet session and events depicted.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<center>[[Telecommunications info | To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_102_232-3_notes&diff=3080My 102 232-3 notes2024-03-25T19:57:15Z<p>Paul: /* Result of interceptions § 4.3.2 */</p>
<hr />
<div>My notes on ETSI TS 102 232-3<br />
<br />
Version 3.8.1 (2020-08) was used as basis.<br />
<br />
== Internet Access Service (IAS) § 4.1 == <br />
<br />
Figure 1 Internet access diagram<br />
<br />
[[File:102-232-3 V3.8.1 Figure1.png|alt=102-232-3 V3.8.1 Figure 1 Internet access diagram|102-232-3 V3.8.1 Figure 1 Internet access diagram]]<br />
<br />
== Lawful Interception Requirements § 4.3 ==<br />
<br />
=== Result of interceptions § 4.3.2 ===<br />
<br />
The network operator, access provider or service provider shall provide Intercept Related Information (IRI), in relation to each target service:<br />
<ol type="a"><br />
<li>When an attempt is made to access the access network.</li><br />
<li>When an access to the access network is permitted.</li><br />
<li>When an access to the access network is not permitted.</li><br />
<li>On change of status (e.g. in the access network).</li><br />
<li>On change of location (this can be related or unrelated to the communication or at all times when the apparatus is switched on).</li><br />
</ol><br />
<br />
The IRI shall contain:<br />
<ol type="a"><br />
<li>Identities used by or associated with the target identity (e.g. dial-in calling line number and called line number, access server identity, Ethernet addresses, access device identifier).</li><br />
<li>Details of services used and their associated parameters.</li><br />
<li>Information relating to status.</li><br />
<li>Timestamps.</li><br />
</ol><br />
<br />
Content of Communication (CC) shall be provided for every IP datagram sent through the IAP's network that:<br />
<ol type="a"><br />
<li>Has the target's IP address as the IP source address.</li><br />
<li>Has the target's IP address as the IP destination address.</li><br />
</ol><br />
<br />
The CC Content of communication shall contain:<br />
<ol type="a"><br />
<li>A stream of octets for every captured datagram, containing a copy of the datagram from layer 3 upwards.</li><br />
</ol><br />
:NOTE: Due to the possibility of IP source address spoofing, the fact that an intercepted packet has the target's IP address as the IP source address does not guarantee that the packet was transmitted by the target; i.e. an intercept in place at the interface connected to the target may not include packets originating from other users spoofing the target's IP address and will not include packets from the actual target that contain a spoofed IP address.<br />
<br />
=== Intercept related information § 4.3.3 ===<br />
<br />
Intercept Related Information (IRI) shall be conveyed to the LEMF in messages, or IRI data records, respectively. Four types of IRI records are defined:<br />
<br />
# IRI-BEGIN record at the first event of a communication attempt, opening the IRI transaction.<br />
# IRI-END record at the end of a communication attempt, closing the IRI transaction.<br />
# IRI-CONTINUE record at any time during a communication attempt within the IRI transaction.<br />
# IRI-REPORT record used in general for non-communication related events.<br />
<br />
For a description of the use and purpose of the various IRI records refer to ETSI TS 102 232-1.<br />
<br />
== IRI events § 6.1 ==<br />
<br />
TODO: Insert Figure 6 state diagram for an Internet session and events depicted.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<center>[[Telecommunications info | To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_102_232-3_notes&diff=3079My 102 232-3 notes2024-03-25T19:44:07Z<p>Paul: </p>
<hr />
<div>My notes on ETSI TS 102 232-3<br />
<br />
Version 3.8.1 (2020-08) was used as basis.<br />
<br />
== Internet Access Service (IAS) § 4.1 == <br />
<br />
Figure 1 Internet access diagram<br />
<br />
[[File:102-232-3 V3.8.1 Figure1.png|alt=102-232-3 V3.8.1 Figure 1 Internet access diagram|102-232-3 V3.8.1 Figure 1 Internet access diagram]]<br />
<br />
== Lawful Interception Requirements § 4.3 ==<br />
<br />
=== Result of interceptions § 4.3.2 ===<br />
<br />
The network operator, access provider or service provider shall provide Intercept Related Information (IRI), in relation to each target service:<br />
<ol type="a"><br />
<li>When an attempt is made to access the access network.</li><br />
<li>When an access to the access network is permitted.</li><br />
<li>When an access to the access network is not permitted.</li><br />
<li>On change of status (e.g. in the access network).</li><br />
<li>On change of location (this can be related or unrelated to the communication or at all times when the apparatus is switched on).</li><br />
</ol><br />
<br />
The IRI shall contain:<br />
<ol type="a"><br />
<li>Identities used by or associated with the target identity (e.g. dial-in calling line number and called line number, access server identity, Ethernet addresses, access device identifier).</li><br />
<li>Details of services used and their associated parameters.</li><br />
<li>Information relating to status.</li><br />
<li>Timestamps.</li><br />
</ol><br />
<br />
Content of Communication (CC) shall be provided for every IP datagram sent through the IAP's network that:<br />
<ol type="a"><br />
<li>Has the target's IP address as the IP source address.</li><br />
<li>Has the target's IP address as the IP destination address.</li><br />
</ol><br />
<br />
The CC Content of communication shall contain:<br />
<ol type="a"><br />
<li>A stream of octets for every captured datagram, containing a copy of the datagram from layer 3 upwards.</li><br />
</ol><br />
:NOTE: Due to the possibility of IP source address spoofing, the fact that an intercepted packet has the target's IP address as the IP source address does not guarantee that the packet was transmitted by the target; i.e. an intercept in place at the interface connected to the target may not include packets originating from other users spoofing the target's IP address and will not include packets from the actual target that contain a spoofed IP address.<br />
<br />
<center>[[Telecommunications info | To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_102_232-3_notes&diff=3078My 102 232-3 notes2024-03-25T19:25:21Z<p>Paul: initial page creation</p>
<hr />
<div><br />
Figure 1 Internet access diagram<br />
<br />
[[File:102-232-3 V3.8.1 Figure1.png|alt=102-232-3 V3.8.1 Figure 1 Internet access diagram|102-232-3 V3.8.1 Figure 1 Internet access diagram]]<br />
<br />
<center>[[Telecommunications info | To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=File:102-232-3_V3.8.1_Figure1.png&diff=3077File:102-232-3 V3.8.1 Figure1.png2024-03-25T19:24:09Z<p>Paul: </p>
<hr />
<div>102-232-3 V3.8.1 Figure1 Internet access</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Telecommunications_info&diff=3076Telecommunications info2024-03-25T17:58:54Z<p>Paul: /* Lawful Interception or Related Standards */</p>
<hr />
<div>== NNI Task Force ==<br />
<br />
[https://www.sipforum.org/activities/nni-task-force-introduction/ NNI Task Force Introduction]<br />
<br />
== 3GPP SA3 Security ==<br />
<br />
[https://www.3gpp.org/specifications-groups/sa-plenary/sa3-security SA3 - Security]<br />
<br />
== [https://www.3gpp.org/specifications/79-specification-numbering 3GPP Standards] ==<br />
<br />
[https://www.3gpp.org/specifications/79-specification-numbering 3GPP specification numbering]<br />
<br />
[https://www.3gpp.org/DynaReport/status-report.htm 3GPP Specification Status Report]<br />
<br />
=== Definition and abbreviations ===<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
=== EPS and NR related standards with notes ===<br />
<br />
[[My New Radio (NR) notes]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Standard # !! Title !! Notes<br />
|-<br />
| 22.011<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service accessibility<br />
| The purpose of 22.011 is to describe the service access procedures as presented to the user. Definitions and procedures are provided in 22.011 for international roaming, national roaming and regionally provided service. These are mandatory in relation to the technical realization of the Mobile Station, or User Equipment (UE).<br />
<br />
[[My 3GPP TS 22.011 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/22261.htm 22.261] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service requirements for the 5G system;<br />
Stage 1<br />
|| Document describes the service and operational requirements for a 5G system, including a UE, NG-RAN, and 5G Core network. Requirements for a 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC are found in TS 22.278.<br />
|-<br />
| 23.122 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode<br />
|| Document gives an overview of the tasks undertaken by the Core network protocols of a Mobile Station (MS) when in idle mode, that is, switched on but typically not having a dedicated channel allocated. It also describes the corresponding network functions. The conditions when the idle mode functions are performed by an MS in the UTRA RRC connected mode states are specified in 3GPP TS 25.331. The conditions when the idle mode functions are performed by an MS in the E-UTRAN are specified in 3GPP TS 36.304. <span style="color:blue">The conditions when the idle mode functions are performed by an MS in the NG-RAN are specified in 3GPP TS 36.304 and 3GPP TS 38.304. The conditions when the idle mode functions are performed by an MS in the NG-RAN RRC inactive state are specified in 3GPP TS 36.331 and 3GPP TS 38.331</span>.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23271.htm 23.271] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Functional stage 2 description of Location Services (LCS)<br />
(Release 16)<br />
|| Document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS, GSM and EPS (for E-UTRAN), which provides the mechanisms to support mobile location services for operators, subscribers and third party service providers. Location Services in 5GC are restricted to regulatory services and are specified in TS 23.501 and TS 23.502 in this release of the specification. The architecture and signalling procedures in NG-RAN are defined in TS 38.305.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3577 23.273] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
5G System (5GS) Location Services (LCS);<br />
Stage 2<br />
|| V17.5.0 document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
General Packet Radio Service (GPRS) enhancements for<br />
Evolved Universal Terrestrial Radio Access Network<br />
(E-UTRAN) access<br />
(Release 17)<br />
|| This document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).<br />
The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 23.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
System architecture for the 5G System (5GS);<br />
Stage 2<br />
|| 5G core network [[My 3GPP 23.501 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145 23.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Procedures for the 5G System (5GS);<br />
Stage 2<br />
| V17.5.0 document defines the Stage 2 procedures and Network Function Services for the 5G system architecture which is described in the TS 23.501 and for the policy and charging control framework which is described in TS 23.503.<br />
<br />
[[My 3GPP 23.502 Notes]]<br />
|-<br />
| 24.229 || Digital cellular telecommunications system (Phase 2+) (GSM);<br>Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);<br>Stage 3 || P-Access-Network-Info values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto" and "gstn-location" are defined in section 7.2A.4<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370 24.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) protocol for 5G System (5GS);<br />
Stage 3;<br />
|| This present document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
[[My 3GPP 24.501 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3371 24.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Access to the 3GPP 5G Core Network (5GCN)<br />
via Non-3GPP Access Networks (N3AN);<br />
Stage 3<br />
|| This document specifies non-3GPP access network discovery and selection procedures, the access authorization procedure used for accessing non-3GPP access networks. These non-3GPP access networks can be trusted non-3GPP access networks, untrusted non-3GPP access networks or wireline access networks.<br />
|-<br />
| 29.503 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
5G System; Unified Data Management Services;<br />
Stage 3<br />
|| The document specifies the stage 3 protocol and data model for the Nudm Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the UDM.<br />
<br />
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.<br />
<br />
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.<br />
|-<br />
| 29.279 || Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>Mobile IPv4 (MIPv4) based mobility protocols;<br>Stage 3 ||<br />
|-<br />
| [https://www.3gpp.org/DynaReport/29571.htm 29.571] || 5G System; Common Data Types for Service Based Interfaces; Stage 3 || The document specifies the stage 3 protocol and data model for common data types that are used or may be expected to be used by multiple Service Based Interface APIs supported by the same or different Network Function(s).<br />
|-<br />
| [https://www.3gpp.org/DynaReport/33501.htm 33.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security architecture and procedures for 5G system<br />
|| Document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
[[My 3GPP 33.501 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/37340.htm 37.340] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
Evolved Universal Terrestrial Radio Access (E-UTRA) and NR;<br />
Multi-connectivity;<br />
Stage 2<br />
|| Document provides an overview of the multi-connectivity operation using E-UTRA and NR radio access technologies.<br />
|-<br />
| 38.300 || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2<br />
|| This document provides an overview and overall description of the NG-RAN and focuses on the radio interface protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the radio interface protocols are specified in companion specifications of the 38 series.<br />
<br />
[[My 3GPP 38.300 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38304.htm 38.304] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
User Equipment (UE) procedures in Idle mode and RRC Inactive state<br />
|| Document specifies the Access Stratum (AS) part of the UE procedures in RRC_IDLE state (also called Idle mode) and RRC_INACTIVE state. The non-access stratum (NAS) part of Idle mode procedures and processes is specified in TS 23.122.<br />
<br />
[[My 3GPP TS 38.304 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197 38.331] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
Radio Resource Control (RRC) protocol specification<br />
(Release 17)<br />
|| This document specifies the Radio Resource Control protocol for the radio interface between UE and NG-RAN.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38401.htm 38.401] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description || Document describes the overall architecture of the NG-RAN, including interfaces NG, Xn and F1 interfaces and their interaction with the radio interface.<br />
<br />
[[My 3GPP TS 38.401 Notes]] <br />
|-<br />
| [https://www.3gpp.org/DynaReport/38413.htm 38.413] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)(Release 16) || This document specifies the radio network layer signalling protocol for the NG interface. The NG Application Protocol (NGAP) supports the functions of the NG interface by signalling procedures defined in this document. NGAP is developed in accordance to the general principles stated in TS 38.401 and TS 38.410.<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|}<br />
<br />
== 3GPP/ETSI info ==<br />
<br />
[https://www.etsi.org/technologies/5g ETSI 5G information page]<br />
<br />
[https://www.etsi.org/technologies/lawful-interception ETSI Lawful Interception (LI) information page]<br />
<br />
[https://www.etsi.org/committee/1403-li ETSI Technical Committee (TC) Lawful Interception information page] and contains list of latest publications<br />
<br />
=== [https://www.etsi.org/standards ETSI Standards] ===<br />
<br />
==== Lawful Interception or Related Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! ETSI Standard<br />
! Title<br />
! Notes<br />
|-<br />
| ETSI TS 102 232-1 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery || This document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks. This document:<br />
* specifies the modular approach used for specifying IP based handover interfaces;<br />
* specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;<br />
* specifies protocols for the transfer of IRI and CC across the handover interfaces;<br />
* specifies protocol profiles for the handover interface.<br />
<br />
[[My 102 232-1 notes]]<br />
|-<br />
| ETSI TS 102 232-2 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 2: Service-specific details for messaging services || This document contains a stage 1 like description of the interception information in relation to the process of sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. Examples of asynchronous messages include: email, unified messaging and chat applications. See 102-232-1 for stage 3.<br />
|-<br />
| ETSI TS 102 232-3 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services || This document contains a stage 1 description of the interception information in relation to the process of binding a "target identity" to an IP address when providing Internet access and a stage 2 description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. The study includes but is not restricted to IRI based on application of Dynamic Host Configuration Protocol (DHCP) and Remote Authentication Dial-In User Service (RADIUS) technology for binding a "target identity" to an IP address and CC for the intercepted IP packets.<br />
<br />
The definition of the Handover Interface 2 (HI2) and Handover Interface 3 (HI3) is outside the scope of the present document. For the handover interface is referred to ETSI TS 102 232-1.<br />
<br />
[[My 102 232-3 notes]]<br />
|-<br />
| ETSI TS 102 232-4 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 4: Service-specific details for Layer 2 services ||<br />
|-<br />
| ETSI TS 102 232-5 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia services || Document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session Initiation Protocol (SIP) and Real Time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IPMM services as described by the Recommendations ITU-T H.323 and H.248-1.<br />
<br />
The present document is consistent with the definition of the Handover Interface, as described in ETSI TS 102 232-1.<br />
<br />
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 and ETSI TS 101 671.<br />
|-<br />
| ETSI TS 102 232-6 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services || <br />
|-<br />
| ETSI TS 102 232-7 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 7: Service-specific details for Mobile Services ||<br />
|-<br />
| ETSI TR 102 528 || Lawful Interception (LI); Interception domain Architecture for IP networks || Document describes a high level reference architecture for supporting lawful interception in network operator (NWO) and communication service providers (SvP) domain for IP networks.<br />
<br />
The document contains:<br />
* A reference model in the network operator (NWO) and communication service provider (SvP) domain.<br />
* A High level description of Internal Network Functions and Interfaces.<br />
* Application of the reference model to voice and multimedia over IP services, data layer 3 and layer 2 services.<br />
|-<br />
| ETSI TS 103 221 || Lawful Interception (LI); Internal Network Interfaces || Part I (X1) and Part II (X2/X3) [[My TS 103 221-2 notes]]<br />
|-<br />
| ETSI TS 103 643 || Techniques for assurance of digital material used in legal proceedings ||<br />
|-<br />
| ETSI TS 101 671 || Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic || Document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is usually mandatory for the operation of any telecommunication service. Step 1 contains the requirements for lawful interception from a users (LEAs) point of view and is published in ETSI TS 101 331. Step 2 describes the derived network functions and the general architecture (or functional model) and is published in ETSI ES 201 158. <br />
|-<br />
| ETSI TS 103 462 || Lawful Interception (LI); Inter LEMF Handover Interface ||<br />
|-<br />
| style="white-space: nowrap;" | ETSI TR 102 503 || Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and Retained data handling Specifications ||<br />
|-<br />
| ETSI TS 102 656 || Lawful Interception (LI); Retained Data; Requirements of Law Enforcement Agencies for handling Retained Data ||<br />
|-<br />
| ETSI TS 102 657 || Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data ||<br />
|-<br />
| ETSI TS 101 331 || Lawful Interception (LI); Requirements of Law Enforcement Agencies || Document gives guidance for lawful interception of telecommunications in the area of co-operation by network operators, access providers, and service providers. Document describes the requirements from a Law Enforcement Agency's (LEA's) point of view.<br />
|-<br />
| ETSI TS 103 707 || Lawful Interception (LI); Handover for messaging services over HTTP/XML || Document specifies the handover details to deliver messaging services for LI over HTTP/XML<br />
|-<br />
| ETSI TS 103 120 || Lawful Interception (LI); Interface for warrant information || Document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception.<br />
|-<br />
| ETSI TS 103 280 || Lawful Interception (LI); Dictionary for common parameters || Document defines a dictionary of parameters that are commonly used in multiple TC LI specifications. Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use. It is encouraged to use the present document in the development of new specifications. [[My ETSI TS 103 280 notes]]<br />
|-<br />
| ETSI TS 103 690 || Lawful Interception (LI); eWarrant Interface || Document presents a high-level description of an interface mechanism - the eWarrant Interface - for receipt of requests for measures producing real-time or stored information by an issuing authority possessing lawful authorization to initiate such a request<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|}<br />
<br />
==== Other Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! 3GPP<br />
! Title<br />
! Notes<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23.003]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17)<br />
|| This document defines the principal purpose and use of different naming, numbering, addressing and identification resources (i.e. Identifiers (ID)) within the digital cellular telecommunications system and the 3GPP system. IDs that are covered by this specification includes both public IDs, private IDs and IDs that are assigned to MSs/UEs. Many of the IDs are used temporary in the networks and are allocated and assigned by the operators and some other IDs are allocated and assigned on either global, regional and national level by an administrator.<br />
<br />
[[My 3GPP TS 23.003 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23228.htm 23.228]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 16)<br />
|| This document defines the stage-2 service description for the IP Multimedia Core Network Subsystem (IMS), which includes the elements necessary to support IP Multimedia (IM) services. [[My 3GPP TS 23.228 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)<br />
|| The document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1014 24.007]<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Mobile radio interface signalling layer 3;<br />
General aspects<br />
(Release 17)<br />
| 24.007 document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the basic message format and error handling applied by the layer 3 protocols.<br />
This document also defines the principal architecture of the EPS NAS and 5GS NAS layer 3 protocol and their sublayers, including the message format applied by layer 3.<br />
<br />
[[My 3GPP TS 24.007 Notes]]<br />
|-<br />
| 33.108 || UMTS; LTE; GSM; 3G Security; Handover interface for lawful interception (LI) || [[My TS 133 108 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3182 33.127] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Lawful Interception (LI) architecture and functions<br />
|| This document specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks. The present document provides an LI architecture supporting both network layer based and service layer based Interception. National regulations determine the specific set of LI functional capabilities that are applicable to a specific 3GPP operator deployment.<br />
<br />
[[My 33.127 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3183 33.128] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Protocol and procedures for Lawful Interception (LI);<br />
Stage 3<br />
|| This document specifies the protocols and procedures required to perform Lawful Interception within a 3GPP network. The present document addresses both internal interfaces used internally with a 3GPP network and external handover interfaces used to handover intercepted communications to law enforcement.<br />
<br />
[[My 33.128 Notes]]<br />
|}<br />
<br />
== Standards related info ==<br />
<br />
MCPTT ID parameter is defined in TS 23.280<br />
<br />
[[My ATIS lawful interception standard notes]]<br />
<br />
[[My lawful interception notes]]<br />
<br />
== RFCs of interest ==<br />
<br />
[https://tools.ietf.org/html/rfc3261 RFC 3261 SIP: Session Initiation Protocol]<br />
<br />
[https://tools.ietf.org/html/rfc3455 RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)]<br />
<br />
[https://tools.ietf.org/html/rfc7913 RFC 7913 P-Access-Network-Info ABNF Update]<br />
<br />
[https://tools.ietf.org/html/rfc4984 RFC 4984 Report from the IAB Workshop on Routing and Addressing]<br />
<br />
[https://tools.ietf.org/html/rfc6830 RFC 6830 The Locator/ID Separation Protocol (LISP)]<br />
<br />
== National Requirements Resources ==<br />
<br />
[https://www.bundesnetzagentur.de/EN/Areas/Telecommunications/Companies/ServicerProviderObligation/PublicSafety/Intercepts/start.html German ], see TR TKÜV. See [[My German LI notes]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Telecommunications_info&diff=3075Telecommunications info2024-03-25T17:58:26Z<p>Paul: /* Lawful Interception or Related Standards */</p>
<hr />
<div>== NNI Task Force ==<br />
<br />
[https://www.sipforum.org/activities/nni-task-force-introduction/ NNI Task Force Introduction]<br />
<br />
== 3GPP SA3 Security ==<br />
<br />
[https://www.3gpp.org/specifications-groups/sa-plenary/sa3-security SA3 - Security]<br />
<br />
== [https://www.3gpp.org/specifications/79-specification-numbering 3GPP Standards] ==<br />
<br />
[https://www.3gpp.org/specifications/79-specification-numbering 3GPP specification numbering]<br />
<br />
[https://www.3gpp.org/DynaReport/status-report.htm 3GPP Specification Status Report]<br />
<br />
=== Definition and abbreviations ===<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
=== EPS and NR related standards with notes ===<br />
<br />
[[My New Radio (NR) notes]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Standard # !! Title !! Notes<br />
|-<br />
| 22.011<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service accessibility<br />
| The purpose of 22.011 is to describe the service access procedures as presented to the user. Definitions and procedures are provided in 22.011 for international roaming, national roaming and regionally provided service. These are mandatory in relation to the technical realization of the Mobile Station, or User Equipment (UE).<br />
<br />
[[My 3GPP TS 22.011 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/22261.htm 22.261] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service requirements for the 5G system;<br />
Stage 1<br />
|| Document describes the service and operational requirements for a 5G system, including a UE, NG-RAN, and 5G Core network. Requirements for a 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC are found in TS 22.278.<br />
|-<br />
| 23.122 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode<br />
|| Document gives an overview of the tasks undertaken by the Core network protocols of a Mobile Station (MS) when in idle mode, that is, switched on but typically not having a dedicated channel allocated. It also describes the corresponding network functions. The conditions when the idle mode functions are performed by an MS in the UTRA RRC connected mode states are specified in 3GPP TS 25.331. The conditions when the idle mode functions are performed by an MS in the E-UTRAN are specified in 3GPP TS 36.304. <span style="color:blue">The conditions when the idle mode functions are performed by an MS in the NG-RAN are specified in 3GPP TS 36.304 and 3GPP TS 38.304. The conditions when the idle mode functions are performed by an MS in the NG-RAN RRC inactive state are specified in 3GPP TS 36.331 and 3GPP TS 38.331</span>.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23271.htm 23.271] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Functional stage 2 description of Location Services (LCS)<br />
(Release 16)<br />
|| Document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS, GSM and EPS (for E-UTRAN), which provides the mechanisms to support mobile location services for operators, subscribers and third party service providers. Location Services in 5GC are restricted to regulatory services and are specified in TS 23.501 and TS 23.502 in this release of the specification. The architecture and signalling procedures in NG-RAN are defined in TS 38.305.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3577 23.273] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
5G System (5GS) Location Services (LCS);<br />
Stage 2<br />
|| V17.5.0 document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
General Packet Radio Service (GPRS) enhancements for<br />
Evolved Universal Terrestrial Radio Access Network<br />
(E-UTRAN) access<br />
(Release 17)<br />
|| This document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).<br />
The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 23.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
System architecture for the 5G System (5GS);<br />
Stage 2<br />
|| 5G core network [[My 3GPP 23.501 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145 23.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Procedures for the 5G System (5GS);<br />
Stage 2<br />
| V17.5.0 document defines the Stage 2 procedures and Network Function Services for the 5G system architecture which is described in the TS 23.501 and for the policy and charging control framework which is described in TS 23.503.<br />
<br />
[[My 3GPP 23.502 Notes]]<br />
|-<br />
| 24.229 || Digital cellular telecommunications system (Phase 2+) (GSM);<br>Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);<br>Stage 3 || P-Access-Network-Info values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto" and "gstn-location" are defined in section 7.2A.4<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370 24.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) protocol for 5G System (5GS);<br />
Stage 3;<br />
|| This present document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
[[My 3GPP 24.501 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3371 24.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Access to the 3GPP 5G Core Network (5GCN)<br />
via Non-3GPP Access Networks (N3AN);<br />
Stage 3<br />
|| This document specifies non-3GPP access network discovery and selection procedures, the access authorization procedure used for accessing non-3GPP access networks. These non-3GPP access networks can be trusted non-3GPP access networks, untrusted non-3GPP access networks or wireline access networks.<br />
|-<br />
| 29.503 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
5G System; Unified Data Management Services;<br />
Stage 3<br />
|| The document specifies the stage 3 protocol and data model for the Nudm Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the UDM.<br />
<br />
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.<br />
<br />
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.<br />
|-<br />
| 29.279 || Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>Mobile IPv4 (MIPv4) based mobility protocols;<br>Stage 3 ||<br />
|-<br />
| [https://www.3gpp.org/DynaReport/29571.htm 29.571] || 5G System; Common Data Types for Service Based Interfaces; Stage 3 || The document specifies the stage 3 protocol and data model for common data types that are used or may be expected to be used by multiple Service Based Interface APIs supported by the same or different Network Function(s).<br />
|-<br />
| [https://www.3gpp.org/DynaReport/33501.htm 33.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security architecture and procedures for 5G system<br />
|| Document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
[[My 3GPP 33.501 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/37340.htm 37.340] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
Evolved Universal Terrestrial Radio Access (E-UTRA) and NR;<br />
Multi-connectivity;<br />
Stage 2<br />
|| Document provides an overview of the multi-connectivity operation using E-UTRA and NR radio access technologies.<br />
|-<br />
| 38.300 || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2<br />
|| This document provides an overview and overall description of the NG-RAN and focuses on the radio interface protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the radio interface protocols are specified in companion specifications of the 38 series.<br />
<br />
[[My 3GPP 38.300 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38304.htm 38.304] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
User Equipment (UE) procedures in Idle mode and RRC Inactive state<br />
|| Document specifies the Access Stratum (AS) part of the UE procedures in RRC_IDLE state (also called Idle mode) and RRC_INACTIVE state. The non-access stratum (NAS) part of Idle mode procedures and processes is specified in TS 23.122.<br />
<br />
[[My 3GPP TS 38.304 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197 38.331] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
Radio Resource Control (RRC) protocol specification<br />
(Release 17)<br />
|| This document specifies the Radio Resource Control protocol for the radio interface between UE and NG-RAN.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38401.htm 38.401] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description || Document describes the overall architecture of the NG-RAN, including interfaces NG, Xn and F1 interfaces and their interaction with the radio interface.<br />
<br />
[[My 3GPP TS 38.401 Notes]] <br />
|-<br />
| [https://www.3gpp.org/DynaReport/38413.htm 38.413] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)(Release 16) || This document specifies the radio network layer signalling protocol for the NG interface. The NG Application Protocol (NGAP) supports the functions of the NG interface by signalling procedures defined in this document. NGAP is developed in accordance to the general principles stated in TS 38.401 and TS 38.410.<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|}<br />
<br />
== 3GPP/ETSI info ==<br />
<br />
[https://www.etsi.org/technologies/5g ETSI 5G information page]<br />
<br />
[https://www.etsi.org/technologies/lawful-interception ETSI Lawful Interception (LI) information page]<br />
<br />
[https://www.etsi.org/committee/1403-li ETSI Technical Committee (TC) Lawful Interception information page] and contains list of latest publications<br />
<br />
=== [https://www.etsi.org/standards ETSI Standards] ===<br />
<br />
==== Lawful Interception or Related Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! ETSI Standard<br />
! Title<br />
! Notes<br />
|-<br />
| ETSI TS 102 232-1 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery || This document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks. This document:<br />
* specifies the modular approach used for specifying IP based handover interfaces;<br />
* specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;<br />
* specifies protocols for the transfer of IRI and CC across the handover interfaces;<br />
* specifies protocol profiles for the handover interface.<br />
|-<br />
| ETSI TS 102 232-2 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 2: Service-specific details for messaging services || This document contains a stage 1 like description of the interception information in relation to the process of sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. Examples of asynchronous messages include: email, unified messaging and chat applications. See 102-232-1 for stage 3.<br />
|-<br />
| ETSI TS 102 232-3 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services || This document contains a stage 1 description of the interception information in relation to the process of binding a "target identity" to an IP address when providing Internet access and a stage 2 description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. The study includes but is not restricted to IRI based on application of Dynamic Host Configuration Protocol (DHCP) and Remote Authentication Dial-In User Service (RADIUS) technology for binding a "target identity" to an IP address and CC for the intercepted IP packets.<br />
<br />
The definition of the Handover Interface 2 (HI2) and Handover Interface 3 (HI3) is outside the scope of the present document. For the handover interface is referred to ETSI TS 102 232-1.<br />
<br />
[[My 102 232-3 notes]]<br />
|-<br />
| ETSI TS 102 232-4 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 4: Service-specific details for Layer 2 services ||<br />
|-<br />
| ETSI TS 102 232-5 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia services || Document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session Initiation Protocol (SIP) and Real Time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IPMM services as described by the Recommendations ITU-T H.323 and H.248-1.<br />
<br />
The present document is consistent with the definition of the Handover Interface, as described in ETSI TS 102 232-1.<br />
<br />
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 and ETSI TS 101 671.<br />
|-<br />
| ETSI TS 102 232-6 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services || <br />
|-<br />
| ETSI TS 102 232-7 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 7: Service-specific details for Mobile Services ||<br />
|-<br />
| ETSI TR 102 528 || Lawful Interception (LI); Interception domain Architecture for IP networks || Document describes a high level reference architecture for supporting lawful interception in network operator (NWO) and communication service providers (SvP) domain for IP networks.<br />
<br />
The document contains:<br />
* A reference model in the network operator (NWO) and communication service provider (SvP) domain.<br />
* A High level description of Internal Network Functions and Interfaces.<br />
* Application of the reference model to voice and multimedia over IP services, data layer 3 and layer 2 services.<br />
|-<br />
| ETSI TS 103 221 || Lawful Interception (LI); Internal Network Interfaces || Part I (X1) and Part II (X2/X3) [[My TS 103 221-2 notes]]<br />
|-<br />
| ETSI TS 103 643 || Techniques for assurance of digital material used in legal proceedings ||<br />
|-<br />
| ETSI TS 101 671 || Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic || Document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is usually mandatory for the operation of any telecommunication service. Step 1 contains the requirements for lawful interception from a users (LEAs) point of view and is published in ETSI TS 101 331. Step 2 describes the derived network functions and the general architecture (or functional model) and is published in ETSI ES 201 158. <br />
|-<br />
| ETSI TS 103 462 || Lawful Interception (LI); Inter LEMF Handover Interface ||<br />
|-<br />
| style="white-space: nowrap;" | ETSI TR 102 503 || Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and Retained data handling Specifications ||<br />
|-<br />
| ETSI TS 102 656 || Lawful Interception (LI); Retained Data; Requirements of Law Enforcement Agencies for handling Retained Data ||<br />
|-<br />
| ETSI TS 102 657 || Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data ||<br />
|-<br />
| ETSI TS 101 331 || Lawful Interception (LI); Requirements of Law Enforcement Agencies || Document gives guidance for lawful interception of telecommunications in the area of co-operation by network operators, access providers, and service providers. Document describes the requirements from a Law Enforcement Agency's (LEA's) point of view.<br />
|-<br />
| ETSI TS 103 707 || Lawful Interception (LI); Handover for messaging services over HTTP/XML || Document specifies the handover details to deliver messaging services for LI over HTTP/XML<br />
|-<br />
| ETSI TS 103 120 || Lawful Interception (LI); Interface for warrant information || Document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception.<br />
|-<br />
| ETSI TS 103 280 || Lawful Interception (LI); Dictionary for common parameters || Document defines a dictionary of parameters that are commonly used in multiple TC LI specifications. Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use. It is encouraged to use the present document in the development of new specifications. [[My ETSI TS 103 280 notes]]<br />
|-<br />
| ETSI TS 103 690 || Lawful Interception (LI); eWarrant Interface || Document presents a high-level description of an interface mechanism - the eWarrant Interface - for receipt of requests for measures producing real-time or stored information by an issuing authority possessing lawful authorization to initiate such a request<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|}<br />
<br />
==== Other Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! 3GPP<br />
! Title<br />
! Notes<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23.003]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17)<br />
|| This document defines the principal purpose and use of different naming, numbering, addressing and identification resources (i.e. Identifiers (ID)) within the digital cellular telecommunications system and the 3GPP system. IDs that are covered by this specification includes both public IDs, private IDs and IDs that are assigned to MSs/UEs. Many of the IDs are used temporary in the networks and are allocated and assigned by the operators and some other IDs are allocated and assigned on either global, regional and national level by an administrator.<br />
<br />
[[My 3GPP TS 23.003 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23228.htm 23.228]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 16)<br />
|| This document defines the stage-2 service description for the IP Multimedia Core Network Subsystem (IMS), which includes the elements necessary to support IP Multimedia (IM) services. [[My 3GPP TS 23.228 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)<br />
|| The document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1014 24.007]<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Mobile radio interface signalling layer 3;<br />
General aspects<br />
(Release 17)<br />
| 24.007 document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the basic message format and error handling applied by the layer 3 protocols.<br />
This document also defines the principal architecture of the EPS NAS and 5GS NAS layer 3 protocol and their sublayers, including the message format applied by layer 3.<br />
<br />
[[My 3GPP TS 24.007 Notes]]<br />
|-<br />
| 33.108 || UMTS; LTE; GSM; 3G Security; Handover interface for lawful interception (LI) || [[My TS 133 108 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3182 33.127] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Lawful Interception (LI) architecture and functions<br />
|| This document specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks. The present document provides an LI architecture supporting both network layer based and service layer based Interception. National regulations determine the specific set of LI functional capabilities that are applicable to a specific 3GPP operator deployment.<br />
<br />
[[My 33.127 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3183 33.128] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Protocol and procedures for Lawful Interception (LI);<br />
Stage 3<br />
|| This document specifies the protocols and procedures required to perform Lawful Interception within a 3GPP network. The present document addresses both internal interfaces used internally with a 3GPP network and external handover interfaces used to handover intercepted communications to law enforcement.<br />
<br />
[[My 33.128 Notes]]<br />
|}<br />
<br />
== Standards related info ==<br />
<br />
MCPTT ID parameter is defined in TS 23.280<br />
<br />
[[My ATIS lawful interception standard notes]]<br />
<br />
[[My lawful interception notes]]<br />
<br />
== RFCs of interest ==<br />
<br />
[https://tools.ietf.org/html/rfc3261 RFC 3261 SIP: Session Initiation Protocol]<br />
<br />
[https://tools.ietf.org/html/rfc3455 RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)]<br />
<br />
[https://tools.ietf.org/html/rfc7913 RFC 7913 P-Access-Network-Info ABNF Update]<br />
<br />
[https://tools.ietf.org/html/rfc4984 RFC 4984 Report from the IAB Workshop on Routing and Addressing]<br />
<br />
[https://tools.ietf.org/html/rfc6830 RFC 6830 The Locator/ID Separation Protocol (LISP)]<br />
<br />
== National Requirements Resources ==<br />
<br />
[https://www.bundesnetzagentur.de/EN/Areas/Telecommunications/Companies/ServicerProviderObligation/PublicSafety/Intercepts/start.html German ], see TR TKÜV. See [[My German LI notes]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Ubuntu&diff=3074Ubuntu2024-02-03T17:07:07Z<p>Paul: /* Resizing logical volume */</p>
<hr />
<div>== Shell commands ==<br />
<br />
Enable root account (not recommended):<br />
<pre>$sudo passwd root</pre><br />
<br />
Disable root account you lock root account:<br />
<pre>$sudo passwd -l root</pre><br />
<br />
Want to use root @ console:<br />
<pre>$sudo -i</pre><br />
<br />
[https://help.ubuntu.com/community/WindowsDualBoot Windows Dual Boot] page<br />
<br />
[https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows Recovering Ubuntu After Windows Install]<br />
<br />
[https://wiki.ubuntu.com/Grub2 Grub2] on Ubuntu wiki<br />
<br />
[http://www.howtogeek.com/howto/43471/how-to-configure-the-linux-grub2-boot-menu-the-easy-way/ Grub2 GUI] Customizer<br />
<br />
For support-related question you can use [https://answers.launchpad.net/ Launchpad]. You can also search the complete history of questions and answers.<br />
<br />
[http://ubuntuforums.org/ Ubuntu web forums]<br />
<br />
[http://ubuntuforums.org/showthread.php?t=1195275 Grub 2] basics<br />
<br />
=== Enable SSH server ===<br />
<br />
<code>apt-get install openssh-server</code><br />
<br />
[https://coderwall.com/p/yz-2_a/limit-ssh-access-by-ip-address Secure SSH server using /etc/hosts.allow]<br />
<br />
=== Add a User ===<br />
<br />
Example adding a user with username johndoe. Follow the instructions provided by the command.<br />
<br />
<code>sudo adduser johndoe</code><br />
<br />
==== sudo group stuff ====<br />
<br />
Add user to sudo group<br />
<br />
<code>sudo usermod -aG sudo <USER_NAME></code><br />
<br />
Verify user belongs to sudo group<br />
<br />
<code>groups <USER_NAME></code><br />
<br />
Verify sudo access<br />
<br />
<code>su - <USER_NAME></code><br />
<br />
Remove user from sudo group<br />
<br />
<code>sudo deluser <USER_NAME> sudo</code><br />
<br />
=== Networking utilities ===<br />
<br />
See IP address information<br />
<br />
<code>ip a</code><br />
<br />
==== Configure hostname ====<br />
<br />
[https://linuxize.com/post/how-to-change-hostname-on-ubuntu-18-04/ How to change hostname on Ubuntu 18 04]<br />
<br />
==== systemctl ====<br />
<br />
Verify which processes run on Ubuntu 18.04 start up use <code>$ sudo systemctl list-unit-files</code>.<br />
<br />
=== Check version of Ubuntu ===<br />
<code>$ cat /etc/os-release</code><br />
<br />
== CLI Software Management ==<br />
<br />
Synchronize package index from Internet. Location of repositories <code>/etc/apt/sources.list</code><br />
<pre>sudo apt-get update</pre><br />
Install newest versions of all software packages<br />
<pre>sudo apt-get upgrade</pre><br />
Update distribution<br />
<pre>sudo apt-get dist-upgrade</pre><br />
Install package (if already installed, will attempt to update package)<br />
<pre>apt-get install package-name</pre><br />
List installed packages<br />
<pre>apt list --installed</pre><br />
<br />
List installed packages that start with 'python'<br />
<pre>$ apt list -a --installed python*</pre><br />
<br />
== Python on Ubuntu Notes ==<br />
<br />
See [[ Python | My Python Notes]] for information not specific to Ubuntu and Python.<br />
<br />
Verify Python 3 is installed<br />
<pre>anon@hammerhead:~$ python --version<br />
<br />
Command 'python' not found, but can be installed with:<br />
<br />
sudo apt install python3 <br />
sudo apt install python <br />
sudo apt install python-minimal<br />
<br />
You also have python3 installed, you can run 'python3' instead.<br />
<br />
anon@hammerhead:~$ python3 --version <----- Python 3 installed.<br />
Python 3.6.7 <----- Version 3.6.7</pre><br />
<br />
Verify Python 3 PIP installed<br />
<pre>$ pip3 --version<br />
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)</pre><br />
<br />
To install Python 3 PIP<br />
<pre>$ sudo apt-get install -y python3-pip</pre><br />
<br />
I use Python virtual environments. Verify Python venv module is installed<br />
<pre>$ apt list -a --installed *venv* <----- If nothing with Python 3 venv comes back then you most install venv module</pre><br />
<br />
To install Python 3 venv module<br />
<pre>$ sudo apt-get install -y python3-venv</pre><br />
<br />
Create virtual environment. I keep my Python virtual environments in a single directory. To create directory <code>$ mkdir python-venv</code><br />
<br />
Switch do directory <code>$ cd python-venv/</code><br />
<br />
Create virtual environment<br />
<pre>$ python3 -m venv udmey-django</pre><br />
<br />
Activate virtual environment<br />
<pre>$ source udmey-django/bin/activate</pre><br />
<br />
Prompt changes to reflect virtual environment<br />
<pre>(udmey-django) anon@hammerhead:~/python-venv$</pre><br />
<br />
Note: Within virtual environment, you can use the command python instead of python3, and pip instead of pip3.<br />
<br />
Deactivate virtual environment and prompt returns to normal<br />
<pre>$ deactivate</pre><br />
<br />
== mongoDB ==<br />
<br />
[[My MongoDB notes]]<br />
<br />
== PostgreSQL ==<br />
<br />
=== Install PostgreSQL ===<br />
<br />
<pre>$ sudo apt install postgresql postgresql-contrib<br />
...<br />
Success. You can now start the database server using:<br />
<br />
/usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start<br />
<br />
Ver Cluster Port Status Owner Data directory Log file<br />
10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log<br />
update-alternatives: using /usr/share/postgresql/10/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode<br />
Setting up postgresql (10+190) ...<br />
Setting up postgresql-contrib (10+190) ...<br />
Processing triggers for systemd (237-3ubuntu10.11) ...<br />
Processing triggers for ureadahead (0.100.0-20) ...</pre><br />
<br />
=== Use PostgreSQL ===<br />
<br />
Switch to postgres account<br />
<pre>sudo -i postgres</pre><br />
Access PostgreSQL prompt<br />
<pre>psql</pre><br />
Exit PostgreSQL prompt<br />
<pre>\q</pre><br />
Log directly into PostgreSQL prompt with postgres user<br />
<pre>sudo -u postgres psql</pre><br />
Add user (username must be same as PostgreSQL role and database)<br />
<pre>sudo adduser user_name</pre><br />
Check current connection information<br />
<pre>\conninfo</pre><br />
<br />
<b>While logged in as postgres user...</b><br />
<br />
Create a new role. Use <code>man createuser</code> for more information.<br />
<pre>createuser --interactive</pre><br />
Create new database<br />
<pre>createdb db_name</pre><br />
Same user connect to different database<br />
<pre>psql -d postgres</pre><br />
<br />
== Nginx ==<br />
<br />
[[My Nginx notes]]<br />
<br />
[https://www.tecmint.com/install-nginx-with-virtual-hosts-and-ssl-certificate/ Install Nginx with virtual hosts and SSL certificates]<br />
<br />
== Apache 2 ==<br />
<br />
=== Resources ===<br />
<br />
[https://help.ubuntu.com/lts/serverguide/httpd.html Ubuntu server guide to HTTPD]<br />
<br />
[https://help.ubuntu.com/community/OpenSSL#SSL_Certificates Ubuntu Open SSL guide]<br />
<br />
[https://help.ubuntu.com/lts/serverguide/certificates-and-security.html.en Ubuntu Certificates and Security]<br />
<br />
[http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html SSL Certificate HOWTO] not Ubuntu specific<br />
<br />
[https://stuff-things.net/2015/09/28/configuring-apache-for-ssl-client-certificate-authentication/ Configure Apache for SSL client certificate authentication]<br />
<br />
=== Installation ===<br />
<br />
Update all your software and install Apache 2<br />
<br />
<pre># apt-get update<br />
# apt-get upgrade<br />
# apt install apache2</pre><br />
<br />
Verify Apache is running<br />
<pre># systemctl status apache2<br />
● apache2.service - The Apache HTTP Server<br />
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)<br />
Drop-In: /lib/systemd/system/apache2.service.d<br />
└─apache2-systemd.conf<br />
Active: active (running) since Sun 2018-10-21 14:44:30 CDT; 11min ago<br />
Main PID: 17131 (apache2)<br />
Tasks: 55 (limit: 4181)<br />
CGroup: /system.slice/apache2.service<br />
├─17131 /usr/sbin/apache2 -k start<br />
├─17132 /usr/sbin/apache2 -k start<br />
└─17134 /usr/sbin/apache2 -k start<br />
<br />
Oct 21 14:44:30 apu02 systemd[1]: Starting The Apache HTTP Server...<br />
Oct 21 14:44:30 apu02 apachectl[17120]: AH00558: apache2: Could not reliably determine the server's<br />
Oct 21 14:44:30 apu02 systemd[1]: Started The Apache HTTP Server.</pre><br />
<br />
=== Firewall ===<br />
<br />
Update firewall to allow only port 443 (default HTTPS TCP port)<br />
<br />
<pre># ufw app list<br />
Available applications:<br />
Apache<br />
Apache Full<br />
Apache Secure<br />
OpenSSH<br />
<br />
# ufw allow 'Apache Secure'<br />
<br />
# ufw status verbose | grep 443<br />
443/tcp (Apache Secure) ALLOW IN Anywhere<br />
443/tcp (Apache Secure (v6)) ALLOW IN Anywhere (v6)</pre><br />
<br />
== Teamspeak 3 setup on Ubuntu 16.04 and 18.x via command line ==<br />
Followed steps at [https://www.vultr.com/docs/how-to-install-teamspeak-3-server-on-ubuntu-16-04-64-bit How to install Teamspeak 3 server on Ubuntu 16.04 64-bit] to install Teamspeak 3 and get basic server running.<br />
<br />
If you want to customize the server port follow next steps.<br />
<br />
Install simple command-line program named [https://www.sqlite.org/cli.html sqlite3]. [https://www.sitepoint.com/getting-started-sqlite3-basic-commands/ How to use sqlite]<br />
<br />
<pre>robot00@apu00:~$ sudo apt install sqlite3</pre><br />
<br />
Launch sqlite3 using Teamspeak 3 sqlite database file:<br />
<br />
<pre>robot00@apu00:~$ sudo sqlite3 /home/teamspeak/ts3server.sqlitedb<br />
SQLite version 3.11.0 2016-02-15 17:29:24<br />
Enter ".help" for usage hints.</pre><br />
<br />
Update port command:<br />
<br />
<pre>sqlite> update servers set server_port=<CUSTOM UDP Port>;</pre><br />
<br />
Restart Teamspeak 3 server<br />
<br />
<pre>robot00@apu00:~$ systemctl restart teamspeak.service</pre><br />
<br />
Test your connection using the <CUSTOM UDP Port><br />
<br />
=== Upgrade Teamspeak3 server ===<br />
<br />
[https://www.gazblog.com/2019/01/update-teamspeak-3-server-on-ubuntu-18-04/ original steps]<br />
<br />
Login to SSH as root<br />
<br />
Stop your current Teamspeak 3 Server <code>systemctl stop teamspeak.service</code><br />
<br />
Change to your teamspeak user <code>cd /home/teamspeak/;su teamspeak</code><br />
<br />
Download Teamspeak, extract it, update and tidy up.<br />
<pre>wget https://files.teamspeak-services.com/releases/server/3.9.1/teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
tar xvfj teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
cd teamspeak3-server_linux_amd64<br />
cp * -R /home/teamspeak<br />
cd ..<br />
rm -r teamspeak3-server_linux_amd64<br />
rm teamspeak3-server_linux_amd64-3.9.1.tar.bz2</pre><br />
<br />
Return to root and start the Teamspeak server<br />
<pre>exit<br />
systemctl start teamspeak.service<br />
</pre><br />
<br />
Check to make you can connect to Teamspeak 3 server<br />
<br />
== Factorio Headless Setup ==<br />
<br />
[[My Factorio Info]]<br />
<br />
== Hardware ==<br />
<br />
Identify video card:<br />
<pre>paul@congo:~$ lspci -nn | grep VGA<br />
01:00.0 VGA compatible controller [0300]: nVidia Corporation G92 [GeForce 8800 GT] [10de:0611] (rev a2)</pre><br />
<br />
Verify interface speed<br />
<br />
<code>cat /sys/class/net/<interface>/speed</code><br />
<br />
replace <interface> with name of your NIC (e.g. eth0)<br />
<br />
[[Ubuntu video card]]<br />
<br />
=== Resizing logical volume ===<br />
<br />
Background<br />
<br />
A 2 TB SSD was physically installed in the system ox and after installation, the LVM used 100 GB.<br />
<br />
Reference [https://community.spiceworks.com/topic/2325763-how-can-i-make-ubuntu-vg-ubuntu-lv-consume-the-entire-disk-space-available How To Make ubuntu-vg-ubuntu-lv Use 100% Free Disc Space]<br />
<br />
<pre>anon@ox:~$ sudo pvs<br />
PV VG Fmt Attr PSize PFree <br />
/dev/nvme0n1p3 ubuntu-vg lvm2 a-- <1.82t <1.72t<br />
<br />
anon@ox:~$ sudo vgs<br />
VG #PV #LV #SN Attr VSize VFree <br />
ubuntu-vg 1 1 0 wz--n- <1.82t <1.72t<br />
<br />
anon@ox:~$ sudo lvs<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
ubuntu-lv ubuntu-vg -wi-ao---- 100.00g # <----------- This shows 100 GB and I want 1.8T.<br />
<br />
anon@ox:~$ sudo lvresize -l +100%FREE /dev/ubuntu-vg/ubuntu-lv<br />
<br />
Size of logical volume ubuntu-vg/ubuntu-lv changed from 100.00 GiB (25600 extents) to <1.82 TiB (476150 extents).<br />
Logical volume ubuntu-vg/ubuntu-lv successfully resized.<br />
<br />
anon@ox:~$ sudo resize2fs /dev/ubuntu-vg/ubuntu-lv<br />
<br />
resize2fs 1.46.5 (30-Dec-2021)<br />
Filesystem at /dev/ubuntu-vg/ubuntu-lv is mounted on /; on-line resizing required<br />
old_desc_blocks = 13, new_desc_blocks = 233<br />
The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 487577600 (4k) blocks long.<br />
<br />
anon@ox:~$ sudo pvs<br />
PV VG Fmt Attr PSize PFree<br />
/dev/nvme0n1p3 ubuntu-vg lvm2 a-- <1.82t 0 <br />
<br />
anon@ox:~$ sudo vgs<br />
VG #PV #LV #SN Attr VSize VFree<br />
ubuntu-vg 1 1 0 wz--n- <1.82t 0 <br />
<br />
anon@ox:~$ sudo lvs<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
ubuntu-lv ubuntu-vg -wi-ao---- <1.82t # <----------- This was 100 GB Size, now it's 1.8T.<br />
<br />
anon@ox:~$ df -h<br />
Filesystem Size Used Avail Use% Mounted on<br />
tmpfs 6.3G 1.9M 6.3G 1% /run<br />
/dev/mapper/ubuntu--vg-ubuntu--lv 1.8T 37G 1.7T 3% / # <----------- This was 100 GB Size, now it's 1.8T.<br />
tmpfs 32G 200K 32G 1% /dev/shm<br />
tmpfs 5.0M 0 5.0M 0% /run/lock<br />
/dev/nvme0n1p2 2.0G 252M 1.6G 14% /boot<br />
/dev/nvme0n1p1 1.1G 6.1M 1.1G 1% /boot/efi<br />
tmpfs 6.3G 4.0K 6.3G 1% /run/user/1001<br />
tmpfs 6.3G 4.0K 6.3G 1% /run/user/1000</pre> <br />
<br />
<center>[[Linux|To Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Ubuntu&diff=3073Ubuntu2024-02-03T17:06:50Z<p>Paul: /* Hardware */</p>
<hr />
<div>== Shell commands ==<br />
<br />
Enable root account (not recommended):<br />
<pre>$sudo passwd root</pre><br />
<br />
Disable root account you lock root account:<br />
<pre>$sudo passwd -l root</pre><br />
<br />
Want to use root @ console:<br />
<pre>$sudo -i</pre><br />
<br />
[https://help.ubuntu.com/community/WindowsDualBoot Windows Dual Boot] page<br />
<br />
[https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows Recovering Ubuntu After Windows Install]<br />
<br />
[https://wiki.ubuntu.com/Grub2 Grub2] on Ubuntu wiki<br />
<br />
[http://www.howtogeek.com/howto/43471/how-to-configure-the-linux-grub2-boot-menu-the-easy-way/ Grub2 GUI] Customizer<br />
<br />
For support-related question you can use [https://answers.launchpad.net/ Launchpad]. You can also search the complete history of questions and answers.<br />
<br />
[http://ubuntuforums.org/ Ubuntu web forums]<br />
<br />
[http://ubuntuforums.org/showthread.php?t=1195275 Grub 2] basics<br />
<br />
=== Enable SSH server ===<br />
<br />
<code>apt-get install openssh-server</code><br />
<br />
[https://coderwall.com/p/yz-2_a/limit-ssh-access-by-ip-address Secure SSH server using /etc/hosts.allow]<br />
<br />
=== Add a User ===<br />
<br />
Example adding a user with username johndoe. Follow the instructions provided by the command.<br />
<br />
<code>sudo adduser johndoe</code><br />
<br />
==== sudo group stuff ====<br />
<br />
Add user to sudo group<br />
<br />
<code>sudo usermod -aG sudo <USER_NAME></code><br />
<br />
Verify user belongs to sudo group<br />
<br />
<code>groups <USER_NAME></code><br />
<br />
Verify sudo access<br />
<br />
<code>su - <USER_NAME></code><br />
<br />
Remove user from sudo group<br />
<br />
<code>sudo deluser <USER_NAME> sudo</code><br />
<br />
=== Networking utilities ===<br />
<br />
See IP address information<br />
<br />
<code>ip a</code><br />
<br />
==== Configure hostname ====<br />
<br />
[https://linuxize.com/post/how-to-change-hostname-on-ubuntu-18-04/ How to change hostname on Ubuntu 18 04]<br />
<br />
==== systemctl ====<br />
<br />
Verify which processes run on Ubuntu 18.04 start up use <code>$ sudo systemctl list-unit-files</code>.<br />
<br />
=== Check version of Ubuntu ===<br />
<code>$ cat /etc/os-release</code><br />
<br />
== CLI Software Management ==<br />
<br />
Synchronize package index from Internet. Location of repositories <code>/etc/apt/sources.list</code><br />
<pre>sudo apt-get update</pre><br />
Install newest versions of all software packages<br />
<pre>sudo apt-get upgrade</pre><br />
Update distribution<br />
<pre>sudo apt-get dist-upgrade</pre><br />
Install package (if already installed, will attempt to update package)<br />
<pre>apt-get install package-name</pre><br />
List installed packages<br />
<pre>apt list --installed</pre><br />
<br />
List installed packages that start with 'python'<br />
<pre>$ apt list -a --installed python*</pre><br />
<br />
== Python on Ubuntu Notes ==<br />
<br />
See [[ Python | My Python Notes]] for information not specific to Ubuntu and Python.<br />
<br />
Verify Python 3 is installed<br />
<pre>anon@hammerhead:~$ python --version<br />
<br />
Command 'python' not found, but can be installed with:<br />
<br />
sudo apt install python3 <br />
sudo apt install python <br />
sudo apt install python-minimal<br />
<br />
You also have python3 installed, you can run 'python3' instead.<br />
<br />
anon@hammerhead:~$ python3 --version <----- Python 3 installed.<br />
Python 3.6.7 <----- Version 3.6.7</pre><br />
<br />
Verify Python 3 PIP installed<br />
<pre>$ pip3 --version<br />
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)</pre><br />
<br />
To install Python 3 PIP<br />
<pre>$ sudo apt-get install -y python3-pip</pre><br />
<br />
I use Python virtual environments. Verify Python venv module is installed<br />
<pre>$ apt list -a --installed *venv* <----- If nothing with Python 3 venv comes back then you most install venv module</pre><br />
<br />
To install Python 3 venv module<br />
<pre>$ sudo apt-get install -y python3-venv</pre><br />
<br />
Create virtual environment. I keep my Python virtual environments in a single directory. To create directory <code>$ mkdir python-venv</code><br />
<br />
Switch do directory <code>$ cd python-venv/</code><br />
<br />
Create virtual environment<br />
<pre>$ python3 -m venv udmey-django</pre><br />
<br />
Activate virtual environment<br />
<pre>$ source udmey-django/bin/activate</pre><br />
<br />
Prompt changes to reflect virtual environment<br />
<pre>(udmey-django) anon@hammerhead:~/python-venv$</pre><br />
<br />
Note: Within virtual environment, you can use the command python instead of python3, and pip instead of pip3.<br />
<br />
Deactivate virtual environment and prompt returns to normal<br />
<pre>$ deactivate</pre><br />
<br />
== mongoDB ==<br />
<br />
[[My MongoDB notes]]<br />
<br />
== PostgreSQL ==<br />
<br />
=== Install PostgreSQL ===<br />
<br />
<pre>$ sudo apt install postgresql postgresql-contrib<br />
...<br />
Success. You can now start the database server using:<br />
<br />
/usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start<br />
<br />
Ver Cluster Port Status Owner Data directory Log file<br />
10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log<br />
update-alternatives: using /usr/share/postgresql/10/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode<br />
Setting up postgresql (10+190) ...<br />
Setting up postgresql-contrib (10+190) ...<br />
Processing triggers for systemd (237-3ubuntu10.11) ...<br />
Processing triggers for ureadahead (0.100.0-20) ...</pre><br />
<br />
=== Use PostgreSQL ===<br />
<br />
Switch to postgres account<br />
<pre>sudo -i postgres</pre><br />
Access PostgreSQL prompt<br />
<pre>psql</pre><br />
Exit PostgreSQL prompt<br />
<pre>\q</pre><br />
Log directly into PostgreSQL prompt with postgres user<br />
<pre>sudo -u postgres psql</pre><br />
Add user (username must be same as PostgreSQL role and database)<br />
<pre>sudo adduser user_name</pre><br />
Check current connection information<br />
<pre>\conninfo</pre><br />
<br />
<b>While logged in as postgres user...</b><br />
<br />
Create a new role. Use <code>man createuser</code> for more information.<br />
<pre>createuser --interactive</pre><br />
Create new database<br />
<pre>createdb db_name</pre><br />
Same user connect to different database<br />
<pre>psql -d postgres</pre><br />
<br />
== Nginx ==<br />
<br />
[[My Nginx notes]]<br />
<br />
[https://www.tecmint.com/install-nginx-with-virtual-hosts-and-ssl-certificate/ Install Nginx with virtual hosts and SSL certificates]<br />
<br />
== Apache 2 ==<br />
<br />
=== Resources ===<br />
<br />
[https://help.ubuntu.com/lts/serverguide/httpd.html Ubuntu server guide to HTTPD]<br />
<br />
[https://help.ubuntu.com/community/OpenSSL#SSL_Certificates Ubuntu Open SSL guide]<br />
<br />
[https://help.ubuntu.com/lts/serverguide/certificates-and-security.html.en Ubuntu Certificates and Security]<br />
<br />
[http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html SSL Certificate HOWTO] not Ubuntu specific<br />
<br />
[https://stuff-things.net/2015/09/28/configuring-apache-for-ssl-client-certificate-authentication/ Configure Apache for SSL client certificate authentication]<br />
<br />
=== Installation ===<br />
<br />
Update all your software and install Apache 2<br />
<br />
<pre># apt-get update<br />
# apt-get upgrade<br />
# apt install apache2</pre><br />
<br />
Verify Apache is running<br />
<pre># systemctl status apache2<br />
● apache2.service - The Apache HTTP Server<br />
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)<br />
Drop-In: /lib/systemd/system/apache2.service.d<br />
└─apache2-systemd.conf<br />
Active: active (running) since Sun 2018-10-21 14:44:30 CDT; 11min ago<br />
Main PID: 17131 (apache2)<br />
Tasks: 55 (limit: 4181)<br />
CGroup: /system.slice/apache2.service<br />
├─17131 /usr/sbin/apache2 -k start<br />
├─17132 /usr/sbin/apache2 -k start<br />
└─17134 /usr/sbin/apache2 -k start<br />
<br />
Oct 21 14:44:30 apu02 systemd[1]: Starting The Apache HTTP Server...<br />
Oct 21 14:44:30 apu02 apachectl[17120]: AH00558: apache2: Could not reliably determine the server's<br />
Oct 21 14:44:30 apu02 systemd[1]: Started The Apache HTTP Server.</pre><br />
<br />
=== Firewall ===<br />
<br />
Update firewall to allow only port 443 (default HTTPS TCP port)<br />
<br />
<pre># ufw app list<br />
Available applications:<br />
Apache<br />
Apache Full<br />
Apache Secure<br />
OpenSSH<br />
<br />
# ufw allow 'Apache Secure'<br />
<br />
# ufw status verbose | grep 443<br />
443/tcp (Apache Secure) ALLOW IN Anywhere<br />
443/tcp (Apache Secure (v6)) ALLOW IN Anywhere (v6)</pre><br />
<br />
== Teamspeak 3 setup on Ubuntu 16.04 and 18.x via command line ==<br />
Followed steps at [https://www.vultr.com/docs/how-to-install-teamspeak-3-server-on-ubuntu-16-04-64-bit How to install Teamspeak 3 server on Ubuntu 16.04 64-bit] to install Teamspeak 3 and get basic server running.<br />
<br />
If you want to customize the server port follow next steps.<br />
<br />
Install simple command-line program named [https://www.sqlite.org/cli.html sqlite3]. [https://www.sitepoint.com/getting-started-sqlite3-basic-commands/ How to use sqlite]<br />
<br />
<pre>robot00@apu00:~$ sudo apt install sqlite3</pre><br />
<br />
Launch sqlite3 using Teamspeak 3 sqlite database file:<br />
<br />
<pre>robot00@apu00:~$ sudo sqlite3 /home/teamspeak/ts3server.sqlitedb<br />
SQLite version 3.11.0 2016-02-15 17:29:24<br />
Enter ".help" for usage hints.</pre><br />
<br />
Update port command:<br />
<br />
<pre>sqlite> update servers set server_port=<CUSTOM UDP Port>;</pre><br />
<br />
Restart Teamspeak 3 server<br />
<br />
<pre>robot00@apu00:~$ systemctl restart teamspeak.service</pre><br />
<br />
Test your connection using the <CUSTOM UDP Port><br />
<br />
=== Upgrade Teamspeak3 server ===<br />
<br />
[https://www.gazblog.com/2019/01/update-teamspeak-3-server-on-ubuntu-18-04/ original steps]<br />
<br />
Login to SSH as root<br />
<br />
Stop your current Teamspeak 3 Server <code>systemctl stop teamspeak.service</code><br />
<br />
Change to your teamspeak user <code>cd /home/teamspeak/;su teamspeak</code><br />
<br />
Download Teamspeak, extract it, update and tidy up.<br />
<pre>wget https://files.teamspeak-services.com/releases/server/3.9.1/teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
tar xvfj teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
cd teamspeak3-server_linux_amd64<br />
cp * -R /home/teamspeak<br />
cd ..<br />
rm -r teamspeak3-server_linux_amd64<br />
rm teamspeak3-server_linux_amd64-3.9.1.tar.bz2</pre><br />
<br />
Return to root and start the Teamspeak server<br />
<pre>exit<br />
systemctl start teamspeak.service<br />
</pre><br />
<br />
Check to make you can connect to Teamspeak 3 server<br />
<br />
== Factorio Headless Setup ==<br />
<br />
[[My Factorio Info]]<br />
<br />
== Hardware ==<br />
<br />
Identify video card:<br />
<pre>paul@congo:~$ lspci -nn | grep VGA<br />
01:00.0 VGA compatible controller [0300]: nVidia Corporation G92 [GeForce 8800 GT] [10de:0611] (rev a2)</pre><br />
<br />
Verify interface speed<br />
<br />
<code>cat /sys/class/net/<interface>/speed</code><br />
<br />
replace <interface> with name of your NIC (e.g. eth0)<br />
<br />
[[Ubuntu video card]]<br />
<br />
=== Resizing logical volume ===<br />
<br />
Background<br />
<br />
A 2 TB SSD was physically installed in the system ox and after installation, the LVM used 100 GB.<br />
<br />
Reference [https://community.spiceworks.com/topic/2325763-how-can-i-make-ubuntu-vg-ubuntu-lv-consume-the-entire-disk-space-available How To Make ubuntu-vg-ubuntu-lv Use 100% Free Disc Space]<br />
<br />
<pre>anon@ox:~$ sudo pvs<br />
<br />
PV VG Fmt Attr PSize PFree <br />
/dev/nvme0n1p3 ubuntu-vg lvm2 a-- <1.82t <1.72t<br />
<br />
anon@ox:~$ sudo vgs<br />
VG #PV #LV #SN Attr VSize VFree <br />
ubuntu-vg 1 1 0 wz--n- <1.82t <1.72t<br />
<br />
anon@ox:~$ sudo lvs<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
ubuntu-lv ubuntu-vg -wi-ao---- 100.00g # <----------- This shows 100 GB and I want 1.8T.<br />
<br />
anon@ox:~$ sudo lvresize -l +100%FREE /dev/ubuntu-vg/ubuntu-lv<br />
<br />
Size of logical volume ubuntu-vg/ubuntu-lv changed from 100.00 GiB (25600 extents) to <1.82 TiB (476150 extents).<br />
Logical volume ubuntu-vg/ubuntu-lv successfully resized.<br />
<br />
anon@ox:~$ sudo resize2fs /dev/ubuntu-vg/ubuntu-lv<br />
<br />
resize2fs 1.46.5 (30-Dec-2021)<br />
Filesystem at /dev/ubuntu-vg/ubuntu-lv is mounted on /; on-line resizing required<br />
old_desc_blocks = 13, new_desc_blocks = 233<br />
The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 487577600 (4k) blocks long.<br />
<br />
anon@ox:~$ sudo pvs<br />
PV VG Fmt Attr PSize PFree<br />
/dev/nvme0n1p3 ubuntu-vg lvm2 a-- <1.82t 0 <br />
<br />
anon@ox:~$ sudo vgs<br />
VG #PV #LV #SN Attr VSize VFree<br />
ubuntu-vg 1 1 0 wz--n- <1.82t 0 <br />
<br />
anon@ox:~$ sudo lvs<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
ubuntu-lv ubuntu-vg -wi-ao---- <1.82t # <----------- This was 100 GB Size, now it's 1.8T.<br />
<br />
anon@ox:~$ df -h<br />
Filesystem Size Used Avail Use% Mounted on<br />
tmpfs 6.3G 1.9M 6.3G 1% /run<br />
/dev/mapper/ubuntu--vg-ubuntu--lv 1.8T 37G 1.7T 3% / # <----------- This was 100 GB Size, now it's 1.8T.<br />
tmpfs 32G 200K 32G 1% /dev/shm<br />
tmpfs 5.0M 0 5.0M 0% /run/lock<br />
/dev/nvme0n1p2 2.0G 252M 1.6G 14% /boot<br />
/dev/nvme0n1p1 1.1G 6.1M 1.1G 1% /boot/efi<br />
tmpfs 6.3G 4.0K 6.3G 1% /run/user/1001<br />
tmpfs 6.3G 4.0K 6.3G 1% /run/user/1000</pre> <br />
<br />
<center>[[Linux|To Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_abbreviation_notes&diff=3072My 3GPP abbreviation notes2024-01-23T15:48:59Z<p>Paul: </p>
<hr />
<div>{| class="wikitable"<br />
|+ My collection of 3GPP (and ETSI) abbreviation notes<br />
|-<br />
! Abbreviation !! Meaning !! Reference !! Notes<br />
|-<br />
| 3GPP || 3rd Generation Partnership Project (3GPP) || [https://www.3gpp.org/about-us/introducing-3gpp 3GPP]<br />
|-<br />
| 5GC || 5G Core Network || 23.501 ||<br />
|-<br />
| 5G DDNMF || 5G Direct Discovery Name Management Function || 23.501 ||<br />
|-<br />
| 5G LAN || 5G Local Area Network || 23.501 ||<br />
|-<br />
| 5GMM || 5GS Mobility Management || 24.501 || 5GMM is a NAS protocol defined in 24.501 that provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
|-<br />
| 5GS || 5G System || 23.501||<br />
|-<br />
| 5GSM || 5GS Session Management || 24.501 || 5GSM is a NAS protocol defined in 24.501 that provides procedures for the handling of 5GS PDU sessions. Together with the bearer control provided by the access stratum, this protocol is used for the control of user-plane resources.<br />
|-<br />
| 5G-AN || 5G Access Network || 23.501 ||<br />
|-<br />
| 5G-AN PDB || 5G Access Network Packet Delay Budget ||23.501||<br />
|-<br />
| 5G-EIR || 5G-Equipment Identity Register || 23.501 ||<br />
|-<br />
| 5G-GUTI || 5G Globally Unique Temporary Identifier || 23.501 ||<br />
|-<br />
| 5G-BRG || 5G Broadband Residential Gateway || 23.501 ||<br />
|-<br />
| 5G-CRG || 5G Cable Residential Gateway || 23.501 ||<br />
|-<br />
| 5G-RG || 5G Residential Gateway || 23.501 ||<br />
|-<br />
| 5G-S-TMSI || 5G S-Temporary Mobile Subscription Identifier || 23.501 ||<br />
|-<br />
| 5G AV || 5G Authentication Vector || 33.501 ||<br />
|-<br />
| 5G GM || 5G Grand Master || 23.501 ||<br />
|-<br />
| 5G HE AV || 5G Home Environment Authentication Vector || 33.501 ||<br />
|-<br />
| 5G NSWO || 5G Non-Seamless WLAN Offload || 23.501 ||<br />
|-<br />
| 5G SE AV || 5G Serving Environment Authentication Vector || 33.501 ||<br />
|-<br />
| 5G VN || 5G Virtual Network || 23.501 ||<br />
|-<br />
| 5QI || 5G QoS Identifier || 23.501 ||<br />
|-<br />
| 5U || 5GS update || 24.501 ||<br />
|-<br />
| ABBA || Anti-Bidding down Between Architectures || 33.501 ||<br />
|-<br />
| ADRF || Analytics Data Repository Function || 23.501 ||<br />
|-<br />
| AEAD || Authenticated Encryption with Associated Data || 55.301 ||<br />
|-<br />
| AES || Advanced Encryption Standard || 33.501 ||<br />
|-<br />
| AF || Application Function || 23.501 ||<br />
|-<br />
| AKA || Authentication and Key Agreement || 33.501 ||<br />
|-<br />
| AKMA || Authentication and Key Management for Applications || 23.501 ||<br />
|-<br />
| AnLF || Analytics Logical Function || 23.501 ||<br />
|-<br />
| AN || Access Network || 23.501 ||<br />
|-<br />
| AMF || Access and Mobility Function || 23.501 ||<br />
|-<br />
| AMF (AUMF) || Authentication Management Field || 33.501 || I use full spelling or AUMF to disambiguate abbreviation from Access and Mobility Function<br />
|-<br />
| ARQ || Automatic Repeat ReQuest || 21.905 ||<br />
|-<br />
| ARPF || Authentication credential Repository and Processing Function || 33.501 ||<br />
|-<br />
| AS || Access Stratum || 23.501 || Between UE and RAN<br />
|-<br />
| ATSSS || Access Traffic Steering, Switching, Splitting || 23.501 ||<br />
|-<br />
| ATSSS-LL || ATSSS Low-Layer || 23.501 ||<br />
|-<br />
| AUSF || Authentication Server Function || 23.501 ||<br />
|-<br />
| AUTN || AUthentication TokeN || 33.501 ||<br />
|-<br />
| AV || Authentication Vector || 33.501 ||<br />
|-<br />
| AV' || transformed Authentication Vector || 33.501 ||<br />
|-<br />
| BAP || Backhaul Adaptation || 33.501 ||<br />
|-<br />
| BCCH || Broadcast Control Channel || 38.300 ||<br />
|-<br />
| BCH || Broadcast Channel || 38.202 ||<br />
|-<br />
| BH || Backhaul || 33.501 ||<br />
|-<br />
| BMCA || Best Master Clock Algorithm || 23.501 ||<br />
|-<br />
| BSF || Binding Support Function || 23.501 ||<br />
|-<br />
| CAG || Closed Access Group || 23.501 ||<br />
|-<br />
| CAPIF || Common API Framework for 3GPP northbound APIs || 23.501 ||<br />
|-<br />
| CC || Content of Communication || 33.127 ||<br />
|-<br />
| CCA || Client Credentials Assertion || 33.501 ||<br />
|-<br />
| CD-SSB || Cell-Defining Synchronization Signal and PBCH block || 38.300 || When an SSB is associated with an RMSI, the SSB is referred to as a Cell-Defining SSB (CD-SSB). A PCell is always associated to a CD-SSB located on the synchronization raster.<br />
|-<br />
| Cell-ID || Cell Identity || 33.501 || Cell-ID as used in TS 38.331<br />
|-<br />
| CH || Credentials Holder || 23.501 ||<br />
|-<br />
| CHF || Charging Function || 23.501 ||<br />
|-<br />
| CHO || Conditional Handover || 33.501 ||<br />
|-<br />
| CIoT || Cellular Internet of Things || 33.501 ||<br />
|-<br />
| cIPX || consumer's IPX || 33.501 ||<br />
|-<br />
| CK || Cipher Key || 33.501 ||<br />
|-<br />
| CK<sub>SRVCC</sub> || Cipher Key for Single Radio Voice Continuity || 33.501 ||<br />
|-<br />
| CM || Connection Management || 24.007 ||<br />
|-<br />
| CN || Core Network || 23.501 ||<br />
|-<br />
| CN PDB || Core Network Packet Delay Budget || 23.501 ||<br />
|-<br />
| CP || Control Plane || 23.501 ||<br />
|-<br />
| CPA || Conditional PSCell Addition || 38.300 ||<br />
|-<br />
| CPC || Conditional PSCell Change || 38.300 ||<br />
|-<br />
| cSEPP || consumer's SEPP || 33.501 ||<br />
|-<br />
| CTR || Counter (mode) || 33.501 ||<br />
|-<br />
| CU || Central Unit || 33.501 || <br />
|-<br />
| DAPS || Dual Active Protocol Stacks|| 23.501 ||<br />
|-<br />
| DCCF || Data Collection Coordination Function || 23.501 ||<br />
|-<br />
| DCS || Default Credentials Server || 23.501 ||<br />
|-<br />
| DL || Downlink || 23.501 ||<br />
|-<br />
| DMRS || Demodulation Reference Signal || 38.300 ||<br />
|-<br />
| DN || Data Network || 23.501 ||<br />
|-<br />
| DNAI || DN Access Identifier || 23.501 ||<br />
|-<br />
| DNN || Data Network Name || 23.501 ||<br />
|-<br />
| DRB || Data Radio Bearers || 38.300 ||<br />
|-<br />
| DRX || Discontinuous Reception || 23.501 ||<br />
|-<br />
| DSMIP || Dual Stack Mobile IP || ||<br />
|-<br />
| DS-TT || Device-side TSN translator || 23.501 || Time Sensitive Networking?<br />
|-<br />
| DU || Distributed Unit || 33.501 ||<br />
|-<br />
| EAC || Early Admission Control || 23.501 ||<br />
|-<br />
| EAP || Extensible Authentication Protocol || 33.501 ||<br />
|-<br />
| EBI || EPS Bearer Identity || 23.501 || EPS is Evolved Packet System<br />
|-<br />
| EDT || Early Data Transmission || 33.501 ||<br />
|-<br />
| EHPLMN || Equivalent Home PLMN || 21.905 ||<br />
|-<br />
| EMSK || Extended Master Session Key || 33.501 ||<br />
|-<br />
| EMM || EPS Mobility Management || 24.501 ||<br />
|-<br />
| EN-DC || E-UTRA-NR Dual Connectivity || 33.501 ||<br />
|-<br />
| ENSI || External Network Slice Information || 33.501 ||<br />
|-<br />
| ePDG || evolved Packet Data Gateway || 23.501 ||<br />
|-<br />
| EPS || Evolved Packet System || 33.501 ||<br />
|-<br />
| EUI || Extended Unique Identifier || 23.501 ||<br />
|-<br />
| FAR || Forwarding Action Rule || 23.501 ||<br />
|-<br />
| FN-BRG || Fixed Network Broadband RG || 23.501 || RG for Residential Gateway<br />
|-<br />
| FN-CRG || Fixed Network Cable RG || 23.501 || RG for Residential Gateway<br />
|-<br />
| FN-RG || Fixed Network RG || 23.501 || RG for Residential Gateway<br />
|-<br />
| FQDN || Fully Qualified Domain Name || 23.501 ||<br />
|-<br />
| gNB || NR Node B || 33.501 ||<br />
|-<br />
| GBA || Generic Bootstrapping Architecture || 23.501 ||<br />
|-<br />
| GEO || Geostationary Orbit || 23.501 ||<br />
|-<br />
| GERAN || GSM EDGE Radio Access Network || [https://www.3gpp.org/specifications-groups/tsg-geran/geran-plenary 3gpp.org] ||<br />
|-<br />
| GFBR || Guaranteed Flow Bit Rate || 23.501 ||<br />
|-<br />
| GIN || Group ID for Network Selection || 23.501 ||<br />
|-<br />
| GMLC || Gateway Mobile Location Center || 23.501 ||<br />
|-<br />
| GMM || GPRS Mobility Management || 24.008 ||<br />
|-<br />
| GPRS || General Packet Radio Service || 23.060 ||<br />
|-<br />
| GPSI || Generic Public Subscription Identifier || 23.501 || GPSI is needed for addressing a 3GPP subscription in different data networks outside of the 3GPP system. The 3GPP system stores within the subscription data the association between the GPSI and the corresponding SUPI.<br />
<br />
GPSIs are public identifiers used both inside and outside of the 3GPP system.<br />
<br />
The GPSI is either an MSISDN or an External Identifier, see TS 23.003. If MSISDN is included in the subscription data, it shall be possible that the same MSISDN value is supported in both 5GS and EPS.<br />
:NOTE: There is no implied 1-to-1 relationship between GPSI and SUPI.<br />
|-<br />
| GSM || Global System for Mobile communications || 33.127<br />
|-<br />
| GUAMI || Globally Unique AMF Identifier || 23.501 || AMF for Access and Mobility Function<br />
|-<br />
| GUTI || Globally Unique Temporary UE Identity || 33.501 ||<br />
|-<br />
| HMTC || High-Performance Machine-Type Communications || 23.501 ||<br />
|-<br />
| HR || Home Routed || 23.501 || Roaming scenario<br />
|-<br />
| HRES || Hash RESponse || 33.501 ||<br />
|-<br />
| HXREX || Hash eXpected RESponse || 33.501 ||<br />
|-<br />
| IAB || Integrated access and backhaul || 23.501 ||<br />
|-<br />
| ICBM || Inter-Cell Beam Management || 38.300 ||<br />
|-<br />
| IK || Integrity Key || 33.501 ||<br />
|-<br />
| IKE || Internet Key Exchange || 33.501 ||<br />
|-<br />
| IK<sub>SRVCC</sub> || Integrity Key for Single Radio Voice Continuity || 33.501 ||<br />
|-<br />
| IMEI/TAC || IMEI Type Allocation Code || 23.501 ||<br />
|-<br />
| IMSI || International Mobile Subscriber Identity || 33.127<br />
|-<br />
| IPUPS || Inter PLMN UP Security || 23.501 ||<br />
|-<br />
| IPX || IP exchange service || 33.501 ||<br />
|-<br />
| I-RNTI || Inactive RNTI || 38.300<br />
|-<br />
| I-SMF || Intermediate SMF || 23.501 ||<br />
|-<br />
| I-UPF || Intermediate UPF || 23.501 ||<br />
|-<br />
| INT-RNTI || Interruption RNTI || 38.300 ||<br />
|-<br />
| IRI || Intercept Related Information || 33.127 ||<br />
|-<br />
| KSI || Key Set Identifier || 33.501 ||<br />
|-<br />
| KSI<sub>SRVCC</sub> || Key Set Identifier for Single Radio Voice Continuity || 33.501 ||<br />
|-<br />
| LADN || Local Area Data Network || 23.501 ||<br />
|-<br />
| LBO || Local Break Out || 23.501 || Roaming scenario<br />
|-<br />
| LD || Lawful Disclosure || ETSI 103.120 ||<br />
|-<br />
| LDID || Lawful Disclosure IDentifier || ETSI 103.280 || LEA shall assign a unique LDID.<br />
|-<br />
| LEO || Low Earth Orbit || 23.501 ||<br />
|-<br />
| LI || Lawful Intercept || 33.501 ||<br />
|-<br />
| LI_HIQR || Lawful Interception Handover Interface Query Response || 33.127<br />
|-<br />
| LI_XER || Lawful Interception Internal Interface Event Record || 33.127<br />
|-<br />
| LI_XQR || Lawful Interception Internal Interface Query Response || 33.127<br />
|-<br />
| LLC || Logical Link Control || 24.007 ||<br />
|-<br />
| LMF || Location Management Function || 23.501 ||<br />
|-<br />
| LoA || Level of Authorization || 23.501 ||<br />
|-<br />
| LPP || LTE Positioning Protocol || 23.501 ||<br />
|-<br />
| LRF || Location Management Function || 23.501 ||<br />
|-<br />
| LTE || Long Term Evolution || 33.127 ||<br />
|-<br />
| MAC || Message Authentication Code || 24.501 ||<br />
|-<br />
| MANO || Management and Orchestration || ||<br />
|-<br />
| MBS || Multicast/Broadcast Service || 23.501 ||<br />
|-<br />
| MBSF || Multicast/Broadcast Service Function || 23.501 ||<br />
|-<br />
| MBSTF || Multicast/Broadcast Service Transport Function || 23.501 ||<br />
|-<br />
| MB-SMF || Multicast/Broadcast Session Management Function || 23.501 ||<br />
|-<br />
| MB-UPF || Multicast/Broadcast User Plane Function || 23.501 ||<br />
|-<br />
| MCX || Mission Critical Service || 23.501 ||<br />
|-<br />
| MDBV || Maximum Data Burst Volume || 23.501 ||<br />
|-<br />
| MDF || Mediation and Delivery Function || 33.127 ||<br />
|-<br />
| MeNB || Master eNB || 33.501 ||<br />
|-<br />
| ME || Mobile Equipment || 21.905 ||<br />
|-<br />
| MEO || Medium Earth Orbit || 23.501 ||<br />
|-<br />
| MFAF || Messaging Framework Adaptor Function || 23.501 ||<br />
|-<br />
| MFBR || Maximum Flow Bit Rate || 23.501 ||<br />
|-<br />
| MIB || Master Information Block || || Referenced in 38.300<br />
|-<br />
| MICO || Mobile Initiated Connection Only || 23.501 ||<br />
|-<br />
| MINT || Minimization of Service Interruption || 23.501 ||<br />
|-<br />
| ML || Machine Learning || 23.501 ||<br />
|-<br />
| MM || Mobility Management || 24.007 ||<br />
|-<br />
| MN || Master Node || 33.501 ||<br />
|-<br />
| MO-EDT || Mobile Originated Early Data Transmission || 33.501 ||<br />
|-<br />
| MT-EDT || Mobile Terminated Early Data Transmission || 33.501 ||<br />
|-<br />
| MPS || Multimedia Priority Service || 23.501 ||<br />
|-<br />
| MPTCP || Multi-Path TCP Protocol || 23.501 ||<br />
|-<br />
| MR-DC || Multi-Radio Dual Connectivity || 38.300 || Further details of MR-DC operation, including Conditional PSCell Addition (CPA) and Conditional PSCell Change (CPC), can be found in TS 37.340.<br />
|-<br />
| MSK || Master Session Key || 33.501 ||<br />
|-<br />
| MTLF || Model Training Logical Function || 23.501 ||<br />
|-<br />
| N3IWF || Non-3GPP Inter-Working Function || 23.501 ||<br />
|-<br />
| N5CW || Non-5G-Capable over WLAN || 23.501 ||<br />
|-<br />
| N5GC || Non-5G Capable || 24.501 ||<br />
|-<br />
| NAI || Network Access Identifier || 23.501 ||<br />
|-<br />
| NAS || Non-Access Stratum || 33.501 || Between UE and Core Network<br />
|-<br />
| NCC || Next Hop Chaining Counter parameter || 33.501 ||<br />
|-<br />
| NCI || NR Cell ID || 33.128 ||<br />
|-<br />
| NDS || Network Domain Security || 33.501 ||<br />
|-<br />
| NEA || Encryption Algorithm for 5G || 33.501 ||<br />
|-<br />
| NEF || Network Exposure Function || 23.501 ||<br />
|-<br />
| NF || Network Function || 23.501 ||<br />
|-<br />
| NG || Next Generation || 33.501 ||<br />
|-<br />
| NG-RAN || 5G (Next Generation) Radio Access Network || 33.501 ||<br />
|-<br />
| NG-C || NG Control Plane || 38.300 || Between NG-RAN node and AMF<br />
|-<br />
| NG-U || NG User Plane || 38.300 || Between NG-RAN and UPF<br />
|-<br />
| ng-eNB || Next Generation Evolved Node-B || 33.501 ||<br />
|-<br />
| ngKSI || Key Set Identifier in 5G || 33.501 ||<br />
|-<br />
| NGAP || Next Generation Application Protocol || 23.501 ||<br />
|-<br />
| NH || Next Hop || 33.501 ||<br />
|-<br />
| NIA || Integrity Algorithm for 5G || 33.501 ||<br />
|-<br />
| NID || Network identifier || 23.501 ||<br />
|-<br />
| NPN || Non-Public Network || 23.501 ||<br />
|-<br />
| NR || New Radio || 23.501 ||<br />
|-<br />
| NR-DC || NR-NR Dual Connectivity || 33.501 ||<br />
|-<br />
| NRF || Network Repository Function || 23.501 ||<br />
|-<br />
| NSAC || Network Slice Admission Control || 23.501 ||<br />
|-<br />
| NSACF || Network Slice Admission Control Function || 23.501 ||<br />
|-<br />
| NSAG || Network Slice AS Group || 23.501 ||<br />
|-<br />
| NSI ID || Network Slice Instance Identifier || 23.501 ||<br />
|-<br />
| NSSAA || Network Slice-Specific Authentication and Authorization || 23.501 ||<br />
|-<br />
| NSSAAF || Network Slice-specific and SNPN Authentication and Authorization Function || 23.501 ||<br />
|-<br />
| NSSAI || Network Slice Selection Assistance Information || 23.501 ||<br />
|-<br />
| NSSF || Network Slice Selection Function || 23.501 ||<br />
|-<br />
| NSSP || Network Slice Selection Policy || 23.501 ||<br />
|-<br />
| NSSRG || Network Slice Simultaneous Registration Group || 23.501 ||<br />
|-<br />
| NSWO || Non-Seamless WLAN offload || 23.501 ||<br />
|-<br />
| NSWOF || Non-seamless WLAN offload Function || 23.501 ||<br />
|-<br />
| NW-TT || Network-side TSN translator || 23.501 ||<br />
|-<br />
| NWDAF || Network Data Analytics Function || 23.501 ||<br />
|-<br />
| NWO || Network Operator || 102 528 ||<br />
|-<br />
| ONN || Onboarding Network || 23.501 ||<br />
|-<br />
| ON-SNPN || Onboarding Standalone Non-Public Network || 23.501 ||<br />
|-<br />
| PBCH || Physical Broadcast Channel || 38.202 ||<br />
|-<br />
| PCell || Primary Cell || 38.300 || See section 7.7<br />
|-<br />
| PCH || Paging Channel || 38.202 ||<br />
|-<br />
| PCF || Policy Control Function || 23.501 ||<br />
|-<br />
| PDB || Packet Delay Budget || 23.501 ||<br />
|-<br />
| PDCCH || Physical Downlink Control Channel || 38.300 ||<br />
|-<br />
| PDCP || Packet Data Convergence Protocol || 38.300 || The layer 2 of NR is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP).<br />
|-<br />
| PDR || Packet Detection Rule || 23.501 ||<br />
|-<br />
| PDSCH || Physical Downlink Shared Channel || 38.300 ||<br />
|-<br />
| PDU || Protocol Data Unit || 23.501 ||<br />
|-<br />
| PDN || Packet Data Network || 33.501 ||<br />
|-<br />
| PEI || Permanent Equipment Identifier || 23.501 ||<br />
|-<br />
| PER || Packet Error Rate || 23.501 ||<br />
|-<br />
| PFD || Packet Flow Description || 23.501 ||<br />
|-<br />
| pIPX || producer's IPX || 33.501 ||<br />
|-<br />
| PMIP || Proxy Mobile IP || ||<br />
|-<br />
| PNI-NPN || Public Network Integrated Non-Public Network || 23.501 ||<br />
|-<br />
| PPD || Paging Policy Differentiation || 23.501 ||<br />
|-<br />
| PPF || Paging Proceed Flag || 23.501 ||<br />
|-<br />
| PPI || Paging Policy Indicator || 23.501 ||<br />
|-<br />
| PRACH || Physical Random Access Channel || 38.300 ||<br />
|-<br />
| PRINS || PRotocol for N32 INterconnect Security || 33.501 ||<br />
|-<br />
| PSA || PDU Session Anchor || 23.501 ||<br />
|-<br />
| pSEPP || producer's SEPP || 33.501 ||<br />
|-<br />
| PSS || Primary Synchronization Signal || 38.300 ||<br />
|-<br />
| PTP || Precision Time Protocol || 23.501 ||<br />
|-<br />
| PUCCH || Physical Uplink Control Channel || 38.300<br />
|-<br />
| PUR || Preconfigured Uplink Resource || 33.501 ||<br />
|-<br />
| PUSCH || Physical Uplink Shared Channel || 38.300 ||<br />
|-<br />
| PVS || Provisioning Server || 23.501 ||<br />
|-<br />
| QFI || QoS Flow Identifier || 23.501 ||<br />
|-<br />
| QoE || Quality of Experience || 23.501 ||<br />
|-<br />
| QoS || Quality of Service || 33.501 ||<br />
|-<br />
| RACH || Random Access Channel || 38.300 ||<br />
|-<br />
| RACS || Radio Capabilities Signalling optimization || 23.501 ||<br />
|-<br />
| (R)AN || (Radio) Access Network || 23.501 ||<br />
|-<br />
| RANAC || RAN-based Notification Area Code || 38.300 ||<br />
|-<br />
| RAND || RANDom number || ??? ||<br />
|-<br />
| RA-RNTI || Random Access RNTI || 38.300 ||<br />
|-<br />
| RB || NR Resource Block || ||<br />
|-<br />
| RES || RESponse || 33.501 ||<br />
|-<br />
| RG || Residential Gateway || 23.501 ||<br />
|-<br />
| RIM || Remote Interference Management || 23.501 ||<br />
|-<br />
| RNA || RAN-based Notification Area || 38.300 ||<br />
|-<br />
| RNAU || RAN-based Notification Area Update || 38.300 ||<br />
|-<br />
| RNTI || Radio Network Temporary Identifier || 38.300 ||<br />
|-<br />
| RPLMN || Registered Public Land Mobile Network || 21.905 ||<br />
|-<br />
| RQA || Reflective QoS Attribute || 23.501 ||<br />
|-<br />
| RQI || Reflective QoS Indication || 23.501 ||<br />
|-<br />
| RR || Radio Resource || 24.007 ||<br />
|-<br />
| RRC || Radio Resource Control || 38.331 ||<br />
|-<br />
| RRM || Radio Resource Management || ||<br />
|-<br />
| RSN || Redundancy Sequence Number || 23.501 ||<br />
|-<br />
| RSRP || Reference Signal Received Power || 38.300 ||<br />
|-<br />
| SA NR || Standalone New Radio || 23.501 ||<br />
|-<br />
| SBA || Service Based Architecture || 23.501 ||<br />
|-<br />
| SBI || Service Based Interface || 23.501 ||<br />
|-<br />
| SCell || Secondary Cell || 38.300 || See section 7.7. The configured set of serving cells for a UE always consists of one PCell and one or more SCells.<br />
|-<br />
| SCG || Secondary Cell Group || 33.501 ||<br />
|-<br />
| SCP || Service Communication Proxy || 23.501 || NFs and NF services can communicate directly, referred to as Direct Communication, or indirectly via the SCP, referred to as Indirect Communication. For more information on communication options, see Annex E and clauses under 6.3.1 and 7.1.2 of 23.501<br />
|-<br />
| SD || Slice Differentiator || 23.501 ||<br />
|-<br />
| SDT || Small Data Transmission || 38.300 ||<br />
|-<br />
| SEAF || Security Anchor Function || 23.501 ||<br />
|-<br />
| SEPP || Secure Edge Protection Proxy || 23.501 ||<br />
|-<br />
| SgNB || Secondary gNB || 33.501 ||<br />
|-<br />
| SGC || Service Gap Control || 24.501 ||<br />
|-<br />
| SIB || System Information Block || 38.300 ||<br />
|-<br />
| SIDF || Subscription Identifier De-concealing Function || 33.501 ||<br />
|-<br />
| SMC || Security Mode Command || 33.501 ||<br />
|-<br />
| SMF || Session Management Function || 23.501 ||<br />
|-<br />
| SMS || Short Message Service || 21.905 ||<br />
|-<br />
| SMSF || Short Message Service Function || 23.501 ||<br />
|-<br />
| SN || Sequence Number || 23.501 ||<br />
|-<br />
| SN || Secondary Node || 33.501 ||<br />
|-<br />
| SN Id || Serving Network Identifier || 33.501 ||<br />
|-<br />
| SNPN || Standalone Non-Public Network || 23.501 ||<br />
|-<br />
| SOR || Steering of Roaming || 23.122 ||<br />
|-<br />
| SPS || Semi-Persistent Scheduling || 38.300 ||<br />
|-<br />
| SRB || Signalling Radio Bearers || 38.300 || Radio bearers are categorized into two groups: data radio bearers (DRB) for user plane data and signalling radio bearers (SRB) for control plane data.<br />
|-<br />
| SS || Synchronization Signal || 38.300 ||<br />
|-<br />
| SSB || SS/PBCH block || 38.300 ||<br />
|-<br />
| SSC || Session and Service Continuity || 23.501 ||<br />
|-<br />
| SSCMSP || Session and Service Continuity Mode Selection Policy || 23.501 ||<br />
|-<br />
| SSS || Secondary Synchronization Signal || 38.300 ||<br />
|-<br />
| SST || Slice/Service Type|| 23.501 ||<br />
|-<br />
| SUCI || Subscription Concealed Identifier || 23.501 ||<br />
|-<br />
| SUPI || Subscription Permanent Identifier || 23.501 ||<br />
|-<br />
| SV || Software Version || 23.501 ||<br />
|-<br />
| SvP || Service Provider || 102 528 ||<br />
|-<br />
| S-NSSAI || Single Network Slice Selection Assistance Information || 23.501 ||<br />
|-<br />
| SO-SNPN || Subscription Owner Standalone Non-Public Network || 23.501 ||<br />
|-<br />
| TA || Tracking Area || 23.501 ||<br />
|-<br />
| TAC || Tracking Area Code || 38.300 ||<br />
|-<br />
| TAI || Tracking Area Identity || 23.501 ||<br />
|-<br />
| TLS || Transport Layer Security || 33.501 ||<br />
|-<br />
| TNAN || Trusted Non-3GPP Access Network || 23.501 ||<br />
|-<br />
| TNAP || Trusted Non-3GPP Access Point || 23.501 ||<br />
|-<br />
| TNGF || Trusted Non-3GPP Gateway Function || 23.501 ||<br />
|-<br />
| TNL || Transport Network Layer || 23.501 ||<br />
|-<br />
| TNLA || Transport Network Layer Association || 23.501 ||<br />
|-<br />
| TSC || Time Sensitive Communication || 23.501 ||<br />
|-<br />
| TSCAI || TSC Assistance Information || 23.501 ||<br />
|-<br />
| TSCTSF || Time Sensitive Communication and Time Synchronization Function || 23.501 ||<br />
|-<br />
| TSN || Time Sensitive Networking || 23.501 ||<br />
|-<br />
| TSN GM || TSN Grand Master || 23.501 ||<br />
|-<br />
| TSP || Traffic Steering Policy || 23.501 ||<br />
|-<br />
| TT || TSN Translator || 23.501 ||<br />
|-<br />
| TWAP || Trusted WLAN Access Point || 33.501 ||<br />
|-<br />
| TWIF || Trusted WLAN Interworking Function || 23.501 ||<br />
|-<br />
| UAS NF || Uncrewed Aerial System Network Function || 23.501 ||<br />
|-<br />
| UCMF || UE radio Capability Management Function || 23.501 ||<br />
|-<br />
| UDM || Unified Data Management || 23.501 ||<br />
|-<br />
| UDR || Unified Data Repository || 23.501 ||<br />
|-<br />
| UDSF || Unstructured Data Storage Function || 23.501 ||<br />
|-<br />
| UE || User Equipment || 33.501 ||<br />
|-<br />
| UEA || UMTS Encryption Algorithm || 33.501 ||<br />
|-<br />
| UIA || UMTS Integrity Algorithm || 33.501 ||<br />
|-<br />
| UL || Uplink || 23.501 ||<br />
|-<br />
| ULR || Update Location Request || 33.501 ||<br />
|-<br />
| UL CL || Uplink Classifier || 23.501 ||<br />
|-<br />
| UMTS || Universal Mobile Telecommunication System || 33.127 ||<br />
|-<br />
| UP || User Plane || 33.501 ||<br />
|-<br />
| UPF || User Plane Function || 23.501 ||<br />
|-<br />
| URLLC || Ultra Reliable Low Latency Communication || 23.501 ||<br />
|-<br />
| URRP-AMF || UE Reachability Request Parameter for AMF || 23.501 ||<br />
|-<br />
| URSP || UE Route Selection Policy || 23.501 ||<br />
|-<br />
| USIM || Universal Subscriber Identity Module || 33.501 ||<br />
|-<br />
| VID || VLAN Identifier || 23.501 ||<br />
|-<br />
| VLAN || Virtual Local Area Network || 23.501 ||<br />
|-<br />
| W-5GAN || Wireline 5G Access Network || 23.501 ||<br />
|-<br />
| W-5GBAN || Wireline BBF Access Network || 23.501 ||<br />
|-<br />
| W-5GCAN || Wireline 5G Cable Access Network || 23.501 ||<br />
|-<br />
| W-AGF || Wireline Access Gateway Function || 23.501 ||<br />
|-<br />
| xIRI || LI_X2 IRI || 33.127 ||<br />
|-<br />
| XRES || eXpected RESponse || 33.501 ||<br />
|}<br />
<br />
<center>[[Telecommunications info|To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Telecommunications_info&diff=3071Telecommunications info2024-01-23T15:47:04Z<p>Paul: /* Lawful Interception Standards */</p>
<hr />
<div>== NNI Task Force ==<br />
<br />
[https://www.sipforum.org/activities/nni-task-force-introduction/ NNI Task Force Introduction]<br />
<br />
== 3GPP SA3 Security ==<br />
<br />
[https://www.3gpp.org/specifications-groups/sa-plenary/sa3-security SA3 - Security]<br />
<br />
== [https://www.3gpp.org/specifications/79-specification-numbering 3GPP Standards] ==<br />
<br />
[https://www.3gpp.org/specifications/79-specification-numbering 3GPP specification numbering]<br />
<br />
[https://www.3gpp.org/DynaReport/status-report.htm 3GPP Specification Status Report]<br />
<br />
=== Definition and abbreviations ===<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
=== EPS and NR related standards with notes ===<br />
<br />
[[My New Radio (NR) notes]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Standard # !! Title !! Notes<br />
|-<br />
| 22.011<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service accessibility<br />
| The purpose of 22.011 is to describe the service access procedures as presented to the user. Definitions and procedures are provided in 22.011 for international roaming, national roaming and regionally provided service. These are mandatory in relation to the technical realization of the Mobile Station, or User Equipment (UE).<br />
<br />
[[My 3GPP TS 22.011 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/22261.htm 22.261] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service requirements for the 5G system;<br />
Stage 1<br />
|| Document describes the service and operational requirements for a 5G system, including a UE, NG-RAN, and 5G Core network. Requirements for a 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC are found in TS 22.278.<br />
|-<br />
| 23.122 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode<br />
|| Document gives an overview of the tasks undertaken by the Core network protocols of a Mobile Station (MS) when in idle mode, that is, switched on but typically not having a dedicated channel allocated. It also describes the corresponding network functions. The conditions when the idle mode functions are performed by an MS in the UTRA RRC connected mode states are specified in 3GPP TS 25.331. The conditions when the idle mode functions are performed by an MS in the E-UTRAN are specified in 3GPP TS 36.304. <span style="color:blue">The conditions when the idle mode functions are performed by an MS in the NG-RAN are specified in 3GPP TS 36.304 and 3GPP TS 38.304. The conditions when the idle mode functions are performed by an MS in the NG-RAN RRC inactive state are specified in 3GPP TS 36.331 and 3GPP TS 38.331</span>.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23271.htm 23.271] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Functional stage 2 description of Location Services (LCS)<br />
(Release 16)<br />
|| Document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS, GSM and EPS (for E-UTRAN), which provides the mechanisms to support mobile location services for operators, subscribers and third party service providers. Location Services in 5GC are restricted to regulatory services and are specified in TS 23.501 and TS 23.502 in this release of the specification. The architecture and signalling procedures in NG-RAN are defined in TS 38.305.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3577 23.273] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
5G System (5GS) Location Services (LCS);<br />
Stage 2<br />
|| V17.5.0 document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
General Packet Radio Service (GPRS) enhancements for<br />
Evolved Universal Terrestrial Radio Access Network<br />
(E-UTRAN) access<br />
(Release 17)<br />
|| This document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).<br />
The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 23.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
System architecture for the 5G System (5GS);<br />
Stage 2<br />
|| 5G core network [[My 3GPP 23.501 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145 23.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Procedures for the 5G System (5GS);<br />
Stage 2<br />
| V17.5.0 document defines the Stage 2 procedures and Network Function Services for the 5G system architecture which is described in the TS 23.501 and for the policy and charging control framework which is described in TS 23.503.<br />
<br />
[[My 3GPP 23.502 Notes]]<br />
|-<br />
| 24.229 || Digital cellular telecommunications system (Phase 2+) (GSM);<br>Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);<br>Stage 3 || P-Access-Network-Info values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto" and "gstn-location" are defined in section 7.2A.4<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370 24.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) protocol for 5G System (5GS);<br />
Stage 3;<br />
|| This present document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
[[My 3GPP 24.501 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3371 24.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Access to the 3GPP 5G Core Network (5GCN)<br />
via Non-3GPP Access Networks (N3AN);<br />
Stage 3<br />
|| This document specifies non-3GPP access network discovery and selection procedures, the access authorization procedure used for accessing non-3GPP access networks. These non-3GPP access networks can be trusted non-3GPP access networks, untrusted non-3GPP access networks or wireline access networks.<br />
|-<br />
| 29.503 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
5G System; Unified Data Management Services;<br />
Stage 3<br />
|| The document specifies the stage 3 protocol and data model for the Nudm Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the UDM.<br />
<br />
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.<br />
<br />
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.<br />
|-<br />
| 29.279 || Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>Mobile IPv4 (MIPv4) based mobility protocols;<br>Stage 3 ||<br />
|-<br />
| [https://www.3gpp.org/DynaReport/29571.htm 29.571] || 5G System; Common Data Types for Service Based Interfaces; Stage 3 || The document specifies the stage 3 protocol and data model for common data types that are used or may be expected to be used by multiple Service Based Interface APIs supported by the same or different Network Function(s).<br />
|-<br />
| [https://www.3gpp.org/DynaReport/33501.htm 33.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security architecture and procedures for 5G system<br />
|| Document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
[[My 3GPP 33.501 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/37340.htm 37.340] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
Evolved Universal Terrestrial Radio Access (E-UTRA) and NR;<br />
Multi-connectivity;<br />
Stage 2<br />
|| Document provides an overview of the multi-connectivity operation using E-UTRA and NR radio access technologies.<br />
|-<br />
| 38.300 || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2<br />
|| This document provides an overview and overall description of the NG-RAN and focuses on the radio interface protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the radio interface protocols are specified in companion specifications of the 38 series.<br />
<br />
[[My 3GPP 38.300 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38304.htm 38.304] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
User Equipment (UE) procedures in Idle mode and RRC Inactive state<br />
|| Document specifies the Access Stratum (AS) part of the UE procedures in RRC_IDLE state (also called Idle mode) and RRC_INACTIVE state. The non-access stratum (NAS) part of Idle mode procedures and processes is specified in TS 23.122.<br />
<br />
[[My 3GPP TS 38.304 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197 38.331] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
Radio Resource Control (RRC) protocol specification<br />
(Release 17)<br />
|| This document specifies the Radio Resource Control protocol for the radio interface between UE and NG-RAN.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38401.htm 38.401] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description || Document describes the overall architecture of the NG-RAN, including interfaces NG, Xn and F1 interfaces and their interaction with the radio interface.<br />
<br />
[[My 3GPP TS 38.401 Notes]] <br />
|-<br />
| [https://www.3gpp.org/DynaReport/38413.htm 38.413] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)(Release 16) || This document specifies the radio network layer signalling protocol for the NG interface. The NG Application Protocol (NGAP) supports the functions of the NG interface by signalling procedures defined in this document. NGAP is developed in accordance to the general principles stated in TS 38.401 and TS 38.410.<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|}<br />
<br />
== 3GPP/ETSI info ==<br />
<br />
[https://www.etsi.org/technologies/5g ETSI 5G information page]<br />
<br />
[https://www.etsi.org/technologies/lawful-interception ETSI Lawful Interception (LI) information page]<br />
<br />
[https://www.etsi.org/committee/1403-li ETSI Technical Committee (TC) Lawful Interception information page] and contains list of latest publications<br />
<br />
=== [https://www.etsi.org/standards ETSI Standards] ===<br />
<br />
==== Lawful Interception or Related Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! ETSI Standard<br />
! Title<br />
! Notes<br />
|-<br />
| ETSI TS 102 232-1 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery || This document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks. This document:<br />
* specifies the modular approach used for specifying IP based handover interfaces;<br />
* specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;<br />
* specifies protocols for the transfer of IRI and CC across the handover interfaces;<br />
* specifies protocol profiles for the handover interface.<br />
|-<br />
| ETSI TS 102 232-2 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 2: Service-specific details for messaging services || This document contains a stage 1 like description of the interception information in relation to the process of sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. Examples of asynchronous messages include: email, unified messaging and chat applications. See 102-232-1 for stage 3.<br />
|-<br />
| ETSI TS 102 232-3 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services ||<br />
|-<br />
| ETSI TS 102 232-4 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 4: Service-specific details for Layer 2 services ||<br />
|-<br />
| ETSI TS 102 232-5 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia services || Document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session Initiation Protocol (SIP) and Real Time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IPMM services as described by the Recommendations ITU-T H.323 and H.248-1.<br />
<br />
The present document is consistent with the definition of the Handover Interface, as described in ETSI TS 102 232-1.<br />
<br />
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 and ETSI TS 101 671.<br />
|-<br />
| ETSI TS 102 232-6 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services || <br />
|-<br />
| ETSI TS 102 232-7 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 7: Service-specific details for Mobile Services ||<br />
|-<br />
| ETSI TR 102 528 || Lawful Interception (LI); Interception domain Architecture for IP networks || Document describes a high level reference architecture for supporting lawful interception in network operator (NWO) and communication service providers (SvP) domain for IP networks.<br />
<br />
The document contains:<br />
* A reference model in the network operator (NWO) and communication service provider (SvP) domain.<br />
* A High level description of Internal Network Functions and Interfaces.<br />
* Application of the reference model to voice and multimedia over IP services, data layer 3 and layer 2 services.<br />
|-<br />
| ETSI TS 103 221 || Lawful Interception (LI); Internal Network Interfaces || Part I (X1) and Part II (X2/X3) [[My TS 103 221-2 notes]]<br />
|-<br />
| ETSI TS 103 643 || Techniques for assurance of digital material used in legal proceedings ||<br />
|-<br />
| ETSI TS 101 671 || Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic || Document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is usually mandatory for the operation of any telecommunication service. Step 1 contains the requirements for lawful interception from a users (LEAs) point of view and is published in ETSI TS 101 331. Step 2 describes the derived network functions and the general architecture (or functional model) and is published in ETSI ES 201 158. <br />
|-<br />
| ETSI TS 103 462 || Lawful Interception (LI); Inter LEMF Handover Interface ||<br />
|-<br />
| style="white-space: nowrap;" | ETSI TR 102 503 || Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and Retained data handling Specifications ||<br />
|-<br />
| ETSI TS 102 656 || Lawful Interception (LI); Retained Data; Requirements of Law Enforcement Agencies for handling Retained Data ||<br />
|-<br />
| ETSI TS 102 657 || Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data ||<br />
|-<br />
| ETSI TS 101 331 || Lawful Interception (LI); Requirements of Law Enforcement Agencies || Document gives guidance for lawful interception of telecommunications in the area of co-operation by network operators, access providers, and service providers. Document describes the requirements from a Law Enforcement Agency's (LEA's) point of view.<br />
|-<br />
| ETSI TS 103 707 || Lawful Interception (LI); Handover for messaging services over HTTP/XML || Document specifies the handover details to deliver messaging services for LI over HTTP/XML<br />
|-<br />
| ETSI TS 103 120 || Lawful Interception (LI); Interface for warrant information || Document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception.<br />
|-<br />
| ETSI TS 103 280 || Lawful Interception (LI); Dictionary for common parameters || Document defines a dictionary of parameters that are commonly used in multiple TC LI specifications. Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use. It is encouraged to use the present document in the development of new specifications. [[My ETSI TS 103 280 notes]]<br />
|-<br />
| ETSI TS 103 690 || Lawful Interception (LI); eWarrant Interface || Document presents a high-level description of an interface mechanism - the eWarrant Interface - for receipt of requests for measures producing real-time or stored information by an issuing authority possessing lawful authorization to initiate such a request<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|}<br />
<br />
==== Other Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! 3GPP<br />
! Title<br />
! Notes<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23.003]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17)<br />
|| This document defines the principal purpose and use of different naming, numbering, addressing and identification resources (i.e. Identifiers (ID)) within the digital cellular telecommunications system and the 3GPP system. IDs that are covered by this specification includes both public IDs, private IDs and IDs that are assigned to MSs/UEs. Many of the IDs are used temporary in the networks and are allocated and assigned by the operators and some other IDs are allocated and assigned on either global, regional and national level by an administrator.<br />
<br />
[[My 3GPP TS 23.003 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23228.htm 23.228]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 16)<br />
|| This document defines the stage-2 service description for the IP Multimedia Core Network Subsystem (IMS), which includes the elements necessary to support IP Multimedia (IM) services. [[My 3GPP TS 23.228 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)<br />
|| The document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1014 24.007]<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Mobile radio interface signalling layer 3;<br />
General aspects<br />
(Release 17)<br />
| 24.007 document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the basic message format and error handling applied by the layer 3 protocols.<br />
This document also defines the principal architecture of the EPS NAS and 5GS NAS layer 3 protocol and their sublayers, including the message format applied by layer 3.<br />
<br />
[[My 3GPP TS 24.007 Notes]]<br />
|-<br />
| 33.108 || UMTS; LTE; GSM; 3G Security; Handover interface for lawful interception (LI) || [[My TS 133 108 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3182 33.127] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Lawful Interception (LI) architecture and functions<br />
|| This document specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks. The present document provides an LI architecture supporting both network layer based and service layer based Interception. National regulations determine the specific set of LI functional capabilities that are applicable to a specific 3GPP operator deployment.<br />
<br />
[[My 33.127 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3183 33.128] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Protocol and procedures for Lawful Interception (LI);<br />
Stage 3<br />
|| This document specifies the protocols and procedures required to perform Lawful Interception within a 3GPP network. The present document addresses both internal interfaces used internally with a 3GPP network and external handover interfaces used to handover intercepted communications to law enforcement.<br />
<br />
[[My 33.128 Notes]]<br />
|}<br />
<br />
== Standards related info ==<br />
<br />
MCPTT ID parameter is defined in TS 23.280<br />
<br />
[[My ATIS lawful interception standard notes]]<br />
<br />
[[My lawful interception notes]]<br />
<br />
== RFCs of interest ==<br />
<br />
[https://tools.ietf.org/html/rfc3261 RFC 3261 SIP: Session Initiation Protocol]<br />
<br />
[https://tools.ietf.org/html/rfc3455 RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)]<br />
<br />
[https://tools.ietf.org/html/rfc7913 RFC 7913 P-Access-Network-Info ABNF Update]<br />
<br />
[https://tools.ietf.org/html/rfc4984 RFC 4984 Report from the IAB Workshop on Routing and Addressing]<br />
<br />
[https://tools.ietf.org/html/rfc6830 RFC 6830 The Locator/ID Separation Protocol (LISP)]<br />
<br />
== National Requirements Resources ==<br />
<br />
[https://www.bundesnetzagentur.de/EN/Areas/Telecommunications/Companies/ServicerProviderObligation/PublicSafety/Intercepts/start.html German ], see TR TKÜV. See [[My German LI notes]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Telecommunications_info&diff=3070Telecommunications info2024-01-11T21:53:35Z<p>Paul: /* Lawful Interception Standards */</p>
<hr />
<div>== NNI Task Force ==<br />
<br />
[https://www.sipforum.org/activities/nni-task-force-introduction/ NNI Task Force Introduction]<br />
<br />
== 3GPP SA3 Security ==<br />
<br />
[https://www.3gpp.org/specifications-groups/sa-plenary/sa3-security SA3 - Security]<br />
<br />
== [https://www.3gpp.org/specifications/79-specification-numbering 3GPP Standards] ==<br />
<br />
[https://www.3gpp.org/specifications/79-specification-numbering 3GPP specification numbering]<br />
<br />
[https://www.3gpp.org/DynaReport/status-report.htm 3GPP Specification Status Report]<br />
<br />
=== Definition and abbreviations ===<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
=== EPS and NR related standards with notes ===<br />
<br />
[[My New Radio (NR) notes]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Standard # !! Title !! Notes<br />
|-<br />
| 22.011<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service accessibility<br />
| The purpose of 22.011 is to describe the service access procedures as presented to the user. Definitions and procedures are provided in 22.011 for international roaming, national roaming and regionally provided service. These are mandatory in relation to the technical realization of the Mobile Station, or User Equipment (UE).<br />
<br />
[[My 3GPP TS 22.011 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/22261.htm 22.261] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service requirements for the 5G system;<br />
Stage 1<br />
|| Document describes the service and operational requirements for a 5G system, including a UE, NG-RAN, and 5G Core network. Requirements for a 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC are found in TS 22.278.<br />
|-<br />
| 23.122 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode<br />
|| Document gives an overview of the tasks undertaken by the Core network protocols of a Mobile Station (MS) when in idle mode, that is, switched on but typically not having a dedicated channel allocated. It also describes the corresponding network functions. The conditions when the idle mode functions are performed by an MS in the UTRA RRC connected mode states are specified in 3GPP TS 25.331. The conditions when the idle mode functions are performed by an MS in the E-UTRAN are specified in 3GPP TS 36.304. <span style="color:blue">The conditions when the idle mode functions are performed by an MS in the NG-RAN are specified in 3GPP TS 36.304 and 3GPP TS 38.304. The conditions when the idle mode functions are performed by an MS in the NG-RAN RRC inactive state are specified in 3GPP TS 36.331 and 3GPP TS 38.331</span>.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23271.htm 23.271] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Functional stage 2 description of Location Services (LCS)<br />
(Release 16)<br />
|| Document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS, GSM and EPS (for E-UTRAN), which provides the mechanisms to support mobile location services for operators, subscribers and third party service providers. Location Services in 5GC are restricted to regulatory services and are specified in TS 23.501 and TS 23.502 in this release of the specification. The architecture and signalling procedures in NG-RAN are defined in TS 38.305.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3577 23.273] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
5G System (5GS) Location Services (LCS);<br />
Stage 2<br />
|| V17.5.0 document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
General Packet Radio Service (GPRS) enhancements for<br />
Evolved Universal Terrestrial Radio Access Network<br />
(E-UTRAN) access<br />
(Release 17)<br />
|| This document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).<br />
The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 23.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
System architecture for the 5G System (5GS);<br />
Stage 2<br />
|| 5G core network [[My 3GPP 23.501 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145 23.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Procedures for the 5G System (5GS);<br />
Stage 2<br />
| V17.5.0 document defines the Stage 2 procedures and Network Function Services for the 5G system architecture which is described in the TS 23.501 and for the policy and charging control framework which is described in TS 23.503.<br />
<br />
[[My 3GPP 23.502 Notes]]<br />
|-<br />
| 24.229 || Digital cellular telecommunications system (Phase 2+) (GSM);<br>Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);<br>Stage 3 || P-Access-Network-Info values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto" and "gstn-location" are defined in section 7.2A.4<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370 24.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) protocol for 5G System (5GS);<br />
Stage 3;<br />
|| This present document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
[[My 3GPP 24.501 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3371 24.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Access to the 3GPP 5G Core Network (5GCN)<br />
via Non-3GPP Access Networks (N3AN);<br />
Stage 3<br />
|| This document specifies non-3GPP access network discovery and selection procedures, the access authorization procedure used for accessing non-3GPP access networks. These non-3GPP access networks can be trusted non-3GPP access networks, untrusted non-3GPP access networks or wireline access networks.<br />
|-<br />
| 29.503 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
5G System; Unified Data Management Services;<br />
Stage 3<br />
|| The document specifies the stage 3 protocol and data model for the Nudm Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the UDM.<br />
<br />
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.<br />
<br />
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.<br />
|-<br />
| 29.279 || Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>Mobile IPv4 (MIPv4) based mobility protocols;<br>Stage 3 ||<br />
|-<br />
| [https://www.3gpp.org/DynaReport/29571.htm 29.571] || 5G System; Common Data Types for Service Based Interfaces; Stage 3 || The document specifies the stage 3 protocol and data model for common data types that are used or may be expected to be used by multiple Service Based Interface APIs supported by the same or different Network Function(s).<br />
|-<br />
| [https://www.3gpp.org/DynaReport/33501.htm 33.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security architecture and procedures for 5G system<br />
|| Document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
[[My 3GPP 33.501 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/37340.htm 37.340] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
Evolved Universal Terrestrial Radio Access (E-UTRA) and NR;<br />
Multi-connectivity;<br />
Stage 2<br />
|| Document provides an overview of the multi-connectivity operation using E-UTRA and NR radio access technologies.<br />
|-<br />
| 38.300 || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2<br />
|| This document provides an overview and overall description of the NG-RAN and focuses on the radio interface protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the radio interface protocols are specified in companion specifications of the 38 series.<br />
<br />
[[My 3GPP 38.300 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38304.htm 38.304] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
User Equipment (UE) procedures in Idle mode and RRC Inactive state<br />
|| Document specifies the Access Stratum (AS) part of the UE procedures in RRC_IDLE state (also called Idle mode) and RRC_INACTIVE state. The non-access stratum (NAS) part of Idle mode procedures and processes is specified in TS 23.122.<br />
<br />
[[My 3GPP TS 38.304 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197 38.331] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
Radio Resource Control (RRC) protocol specification<br />
(Release 17)<br />
|| This document specifies the Radio Resource Control protocol for the radio interface between UE and NG-RAN.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38401.htm 38.401] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description || Document describes the overall architecture of the NG-RAN, including interfaces NG, Xn and F1 interfaces and their interaction with the radio interface.<br />
<br />
[[My 3GPP TS 38.401 Notes]] <br />
|-<br />
| [https://www.3gpp.org/DynaReport/38413.htm 38.413] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)(Release 16) || This document specifies the radio network layer signalling protocol for the NG interface. The NG Application Protocol (NGAP) supports the functions of the NG interface by signalling procedures defined in this document. NGAP is developed in accordance to the general principles stated in TS 38.401 and TS 38.410.<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|}<br />
<br />
== 3GPP/ETSI info ==<br />
<br />
[https://www.etsi.org/technologies/5g ETSI 5G information page]<br />
<br />
[https://www.etsi.org/technologies/lawful-interception ETSI Lawful Interception (LI) information page]<br />
<br />
[https://www.etsi.org/committee/1403-li ETSI Technical Committee (TC) Lawful Interception information page] and contains list of latest publications<br />
<br />
=== [https://www.etsi.org/standards ETSI Standards] ===<br />
<br />
==== Lawful Interception Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! ETSI Standard<br />
! Title<br />
! Notes<br />
|-<br />
| ETSI TS 102 232-1 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery || This document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks. This document:<br />
* specifies the modular approach used for specifying IP based handover interfaces;<br />
* specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;<br />
* specifies protocols for the transfer of IRI and CC across the handover interfaces;<br />
* specifies protocol profiles for the handover interface.<br />
|-<br />
| ETSI TS 102 232-2 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 2: Service-specific details for messaging services || This document contains a stage 1 like description of the interception information in relation to the process of sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. Examples of asynchronous messages include: email, unified messaging and chat applications. See 102-232-1 for stage 3.<br />
|-<br />
| ETSI TS 102 232-3 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services ||<br />
|-<br />
| ETSI TS 102 232-4 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 4: Service-specific details for Layer 2 services ||<br />
|-<br />
| ETSI TS 102 232-5 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia services || Document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session Initiation Protocol (SIP) and Real Time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IPMM services as described by the Recommendations ITU-T H.323 and H.248-1.<br />
<br />
The present document is consistent with the definition of the Handover Interface, as described in ETSI TS 102 232-1.<br />
<br />
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 and ETSI TS 101 671.<br />
|-<br />
| ETSI TS 102 232-6 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services || <br />
|-<br />
| ETSI TS 102 232-7 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 7: Service-specific details for Mobile Services ||<br />
|-<br />
| ETSI TS 103 221 || Lawful Interception (LI); Internal Network Interfaces || Part I (X1) and Part II (X2/X3) [[My TS 103 221-2 notes]]<br />
|-<br />
| ETSI TS 103 643 || Techniques for assurance of digital material used in legal proceedings ||<br />
|-<br />
| ETSI TS 101 671 || Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic || Document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is usually mandatory for the operation of any telecommunication service. Step 1 contains the requirements for lawful interception from a users (LEAs) point of view and is published in ETSI TS 101 331. Step 2 describes the derived network functions and the general architecture (or functional model) and is published in ETSI ES 201 158. <br />
|-<br />
| ETSI TS 103 462 || Lawful Interception (LI); Inter LEMF Handover Interface ||<br />
|-<br />
| style="white-space: nowrap;" | ETSI TR 102 503 || Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and Retained data handling Specifications ||<br />
|-<br />
| ETSI TS 102 656 || Lawful Interception (LI); Retained Data; Requirements of Law Enforcement Agencies for handling Retained Data ||<br />
|-<br />
| ETSI TS 102 657 || Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data ||<br />
|-<br />
| ETSI TS 101 331 || Lawful Interception (LI); Requirements of Law Enforcement Agencies || Document gives guidance for lawful interception of telecommunications in the area of co-operation by network operators, access providers, and service providers. Document describes the requirements from a Law Enforcement Agency's (LEA's) point of view.<br />
|-<br />
| ETSI TS 103 707 || Lawful Interception (LI); Handover for messaging services over HTTP/XML || Document specifies the handover details to deliver messaging services for LI over HTTP/XML<br />
|-<br />
| ETSI TS 103 120 || Lawful Interception (LI); Interface for warrant information || Document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception.<br />
|-<br />
| ETSI TS 103 280 || Lawful Interception (LI); Dictionary for common parameters || Document defines a dictionary of parameters that are commonly used in multiple TC LI specifications. Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use. It is encouraged to use the present document in the development of new specifications. [[My ETSI TS 103 280 notes]]<br />
|-<br />
| ETSI TS 103 690 || Lawful Interception (LI); eWarrant Interface || Document presents a high-level description of an interface mechanism - the eWarrant Interface - for receipt of requests for measures producing real-time or stored information by an issuing authority possessing lawful authorization to initiate such a request<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|}<br />
<br />
==== Other Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! 3GPP<br />
! Title<br />
! Notes<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23.003]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17)<br />
|| This document defines the principal purpose and use of different naming, numbering, addressing and identification resources (i.e. Identifiers (ID)) within the digital cellular telecommunications system and the 3GPP system. IDs that are covered by this specification includes both public IDs, private IDs and IDs that are assigned to MSs/UEs. Many of the IDs are used temporary in the networks and are allocated and assigned by the operators and some other IDs are allocated and assigned on either global, regional and national level by an administrator.<br />
<br />
[[My 3GPP TS 23.003 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23228.htm 23.228]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 16)<br />
|| This document defines the stage-2 service description for the IP Multimedia Core Network Subsystem (IMS), which includes the elements necessary to support IP Multimedia (IM) services. [[My 3GPP TS 23.228 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)<br />
|| The document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1014 24.007]<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Mobile radio interface signalling layer 3;<br />
General aspects<br />
(Release 17)<br />
| 24.007 document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the basic message format and error handling applied by the layer 3 protocols.<br />
This document also defines the principal architecture of the EPS NAS and 5GS NAS layer 3 protocol and their sublayers, including the message format applied by layer 3.<br />
<br />
[[My 3GPP TS 24.007 Notes]]<br />
|-<br />
| 33.108 || UMTS; LTE; GSM; 3G Security; Handover interface for lawful interception (LI) || [[My TS 133 108 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3182 33.127] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Lawful Interception (LI) architecture and functions<br />
|| This document specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks. The present document provides an LI architecture supporting both network layer based and service layer based Interception. National regulations determine the specific set of LI functional capabilities that are applicable to a specific 3GPP operator deployment.<br />
<br />
[[My 33.127 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3183 33.128] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Protocol and procedures for Lawful Interception (LI);<br />
Stage 3<br />
|| This document specifies the protocols and procedures required to perform Lawful Interception within a 3GPP network. The present document addresses both internal interfaces used internally with a 3GPP network and external handover interfaces used to handover intercepted communications to law enforcement.<br />
<br />
[[My 33.128 Notes]]<br />
|}<br />
<br />
== Standards related info ==<br />
<br />
MCPTT ID parameter is defined in TS 23.280<br />
<br />
[[My ATIS lawful interception standard notes]]<br />
<br />
[[My lawful interception notes]]<br />
<br />
== RFCs of interest ==<br />
<br />
[https://tools.ietf.org/html/rfc3261 RFC 3261 SIP: Session Initiation Protocol]<br />
<br />
[https://tools.ietf.org/html/rfc3455 RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)]<br />
<br />
[https://tools.ietf.org/html/rfc7913 RFC 7913 P-Access-Network-Info ABNF Update]<br />
<br />
[https://tools.ietf.org/html/rfc4984 RFC 4984 Report from the IAB Workshop on Routing and Addressing]<br />
<br />
[https://tools.ietf.org/html/rfc6830 RFC 6830 The Locator/ID Separation Protocol (LISP)]<br />
<br />
== National Requirements Resources ==<br />
<br />
[https://www.bundesnetzagentur.de/EN/Areas/Telecommunications/Companies/ServicerProviderObligation/PublicSafety/Intercepts/start.html German ], see TR TKÜV. See [[My German LI notes]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Telecommunications_info&diff=3069Telecommunications info2024-01-11T21:38:07Z<p>Paul: /* Lawful Interception Standards */</p>
<hr />
<div>== NNI Task Force ==<br />
<br />
[https://www.sipforum.org/activities/nni-task-force-introduction/ NNI Task Force Introduction]<br />
<br />
== 3GPP SA3 Security ==<br />
<br />
[https://www.3gpp.org/specifications-groups/sa-plenary/sa3-security SA3 - Security]<br />
<br />
== [https://www.3gpp.org/specifications/79-specification-numbering 3GPP Standards] ==<br />
<br />
[https://www.3gpp.org/specifications/79-specification-numbering 3GPP specification numbering]<br />
<br />
[https://www.3gpp.org/DynaReport/status-report.htm 3GPP Specification Status Report]<br />
<br />
=== Definition and abbreviations ===<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
=== EPS and NR related standards with notes ===<br />
<br />
[[My New Radio (NR) notes]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Standard # !! Title !! Notes<br />
|-<br />
| 22.011<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service accessibility<br />
| The purpose of 22.011 is to describe the service access procedures as presented to the user. Definitions and procedures are provided in 22.011 for international roaming, national roaming and regionally provided service. These are mandatory in relation to the technical realization of the Mobile Station, or User Equipment (UE).<br />
<br />
[[My 3GPP TS 22.011 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/22261.htm 22.261] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service requirements for the 5G system;<br />
Stage 1<br />
|| Document describes the service and operational requirements for a 5G system, including a UE, NG-RAN, and 5G Core network. Requirements for a 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC are found in TS 22.278.<br />
|-<br />
| 23.122 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode<br />
|| Document gives an overview of the tasks undertaken by the Core network protocols of a Mobile Station (MS) when in idle mode, that is, switched on but typically not having a dedicated channel allocated. It also describes the corresponding network functions. The conditions when the idle mode functions are performed by an MS in the UTRA RRC connected mode states are specified in 3GPP TS 25.331. The conditions when the idle mode functions are performed by an MS in the E-UTRAN are specified in 3GPP TS 36.304. <span style="color:blue">The conditions when the idle mode functions are performed by an MS in the NG-RAN are specified in 3GPP TS 36.304 and 3GPP TS 38.304. The conditions when the idle mode functions are performed by an MS in the NG-RAN RRC inactive state are specified in 3GPP TS 36.331 and 3GPP TS 38.331</span>.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23271.htm 23.271] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Functional stage 2 description of Location Services (LCS)<br />
(Release 16)<br />
|| Document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS, GSM and EPS (for E-UTRAN), which provides the mechanisms to support mobile location services for operators, subscribers and third party service providers. Location Services in 5GC are restricted to regulatory services and are specified in TS 23.501 and TS 23.502 in this release of the specification. The architecture and signalling procedures in NG-RAN are defined in TS 38.305.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3577 23.273] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
5G System (5GS) Location Services (LCS);<br />
Stage 2<br />
|| V17.5.0 document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
General Packet Radio Service (GPRS) enhancements for<br />
Evolved Universal Terrestrial Radio Access Network<br />
(E-UTRAN) access<br />
(Release 17)<br />
|| This document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).<br />
The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 23.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
System architecture for the 5G System (5GS);<br />
Stage 2<br />
|| 5G core network [[My 3GPP 23.501 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145 23.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Procedures for the 5G System (5GS);<br />
Stage 2<br />
| V17.5.0 document defines the Stage 2 procedures and Network Function Services for the 5G system architecture which is described in the TS 23.501 and for the policy and charging control framework which is described in TS 23.503.<br />
<br />
[[My 3GPP 23.502 Notes]]<br />
|-<br />
| 24.229 || Digital cellular telecommunications system (Phase 2+) (GSM);<br>Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);<br>Stage 3 || P-Access-Network-Info values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto" and "gstn-location" are defined in section 7.2A.4<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370 24.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) protocol for 5G System (5GS);<br />
Stage 3;<br />
|| This present document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
[[My 3GPP 24.501 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3371 24.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Access to the 3GPP 5G Core Network (5GCN)<br />
via Non-3GPP Access Networks (N3AN);<br />
Stage 3<br />
|| This document specifies non-3GPP access network discovery and selection procedures, the access authorization procedure used for accessing non-3GPP access networks. These non-3GPP access networks can be trusted non-3GPP access networks, untrusted non-3GPP access networks or wireline access networks.<br />
|-<br />
| 29.503 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
5G System; Unified Data Management Services;<br />
Stage 3<br />
|| The document specifies the stage 3 protocol and data model for the Nudm Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the UDM.<br />
<br />
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.<br />
<br />
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.<br />
|-<br />
| 29.279 || Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>Mobile IPv4 (MIPv4) based mobility protocols;<br>Stage 3 ||<br />
|-<br />
| [https://www.3gpp.org/DynaReport/29571.htm 29.571] || 5G System; Common Data Types for Service Based Interfaces; Stage 3 || The document specifies the stage 3 protocol and data model for common data types that are used or may be expected to be used by multiple Service Based Interface APIs supported by the same or different Network Function(s).<br />
|-<br />
| [https://www.3gpp.org/DynaReport/33501.htm 33.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security architecture and procedures for 5G system<br />
|| Document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
[[My 3GPP 33.501 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/37340.htm 37.340] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
Evolved Universal Terrestrial Radio Access (E-UTRA) and NR;<br />
Multi-connectivity;<br />
Stage 2<br />
|| Document provides an overview of the multi-connectivity operation using E-UTRA and NR radio access technologies.<br />
|-<br />
| 38.300 || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2<br />
|| This document provides an overview and overall description of the NG-RAN and focuses on the radio interface protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the radio interface protocols are specified in companion specifications of the 38 series.<br />
<br />
[[My 3GPP 38.300 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38304.htm 38.304] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
User Equipment (UE) procedures in Idle mode and RRC Inactive state<br />
|| Document specifies the Access Stratum (AS) part of the UE procedures in RRC_IDLE state (also called Idle mode) and RRC_INACTIVE state. The non-access stratum (NAS) part of Idle mode procedures and processes is specified in TS 23.122.<br />
<br />
[[My 3GPP TS 38.304 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197 38.331] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
Radio Resource Control (RRC) protocol specification<br />
(Release 17)<br />
|| This document specifies the Radio Resource Control protocol for the radio interface between UE and NG-RAN.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38401.htm 38.401] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description || Document describes the overall architecture of the NG-RAN, including interfaces NG, Xn and F1 interfaces and their interaction with the radio interface.<br />
<br />
[[My 3GPP TS 38.401 Notes]] <br />
|-<br />
| [https://www.3gpp.org/DynaReport/38413.htm 38.413] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)(Release 16) || This document specifies the radio network layer signalling protocol for the NG interface. The NG Application Protocol (NGAP) supports the functions of the NG interface by signalling procedures defined in this document. NGAP is developed in accordance to the general principles stated in TS 38.401 and TS 38.410.<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|}<br />
<br />
== 3GPP/ETSI info ==<br />
<br />
[https://www.etsi.org/technologies/5g ETSI 5G information page]<br />
<br />
[https://www.etsi.org/technologies/lawful-interception ETSI Lawful Interception (LI) information page]<br />
<br />
[https://www.etsi.org/committee/1403-li ETSI Technical Committee (TC) Lawful Interception information page] and contains list of latest publications<br />
<br />
=== [https://www.etsi.org/standards ETSI Standards] ===<br />
<br />
==== Lawful Interception Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! ETSI Standard<br />
! Title<br />
! Notes<br />
|-<br />
| ETSI TS 102 232-1 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery || This document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks. This document:<br />
* specifies the modular approach used for specifying IP based handover interfaces;<br />
* specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;<br />
* specifies protocols for the transfer of IRI and CC across the handover interfaces;<br />
* specifies protocol profiles for the handover interface.<br />
|-<br />
| ETSI TS 102 232-2 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 2: Service-specific details for messaging services || This document contains a stage 1 like description of the interception information in relation to the process of sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. Examples of asynchronous messages include: email, unified messaging and chat applications. See 102-232-1 for stage 3.<br />
|-<br />
| ETSI TS 102 232-3 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services ||<br />
|-<br />
| ETSI TS 102 232-4 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 4: Service-specific details for Layer 2 services ||<br />
|-<br />
| ETSI TS 102 232-5 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia services || Document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session Initiation Protocol (SIP) and Real Time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IP<br />
MM services as described by the Recommendations ITU-T H.323 and H.248-1.<br />
<br />
The present document is consistent with the definition of the Handover Interface, as described in ETSI TS 102 232-1.<br />
<br />
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 and ETSI TS 101 671.<br />
|-<br />
| ETSI TS 102 232-6 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services || <br />
|-<br />
| ETSI TS 102 232-7 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 7: Service-specific details for Mobile Services ||<br />
|-<br />
| ETSI TS 103 221 || Lawful Interception (LI); Internal Network Interfaces || Part I (X1) and Part II (X2/X3) [[My TS 103 221-2 notes]]<br />
|-<br />
| ETSI TS 103 643 || Techniques for assurance of digital material used in legal proceedings ||<br />
|-<br />
| ETSI TS 101 671 || Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic || Document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is usually mandatory for the operation of any telecommunication service. Step 1 contains the requirements for lawful interception from a users (LEAs) point of view and is published in ETSI TS 101 331. Step 2 describes the derived network functions and the general architecture (or functional model) and is published in ETSI ES 201 158. <br />
|-<br />
| ETSI TS 103 462 || Lawful Interception (LI); Inter LEMF Handover Interface ||<br />
|-<br />
| style="white-space: nowrap;" | ETSI TR 102 503 || Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and Retained data handling Specifications ||<br />
|-<br />
| ETSI TS 102 656 || Lawful Interception (LI); Retained Data; Requirements of Law Enforcement Agencies for handling Retained Data ||<br />
|-<br />
| ETSI TS 102 657 || Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data ||<br />
|-<br />
| ETSI TS 101 331 || Lawful Interception (LI); Requirements of Law Enforcement Agencies || Document gives guidance for lawful interception of telecommunications in the area of co-operation by network operators, access providers, and service providers. Document describes the requirements from a Law Enforcement Agency's (LEA's) point of view.<br />
|-<br />
| ETSI TS 103 707 || Lawful Interception (LI); Handover for messaging services over HTTP/XML || Document specifies the handover details to deliver messaging services for LI over HTTP/XML<br />
|-<br />
| ETSI TS 103 120 || Lawful Interception (LI); Interface for warrant information || Document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception.<br />
|-<br />
| ETSI TS 103 280 || Lawful Interception (LI); Dictionary for common parameters || Document defines a dictionary of parameters that are commonly used in multiple TC LI specifications. Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use. It is encouraged to use the present document in the development of new specifications. [[My ETSI TS 103 280 notes]]<br />
|-<br />
| ETSI TS 103 690 || Lawful Interception (LI); eWarrant Interface || Document presents a high-level description of an interface mechanism - the eWarrant Interface - for receipt of requests for measures producing real-time or stored information by an issuing authority possessing lawful authorization to initiate such a request<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|}<br />
<br />
==== Other Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! 3GPP<br />
! Title<br />
! Notes<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23.003]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17)<br />
|| This document defines the principal purpose and use of different naming, numbering, addressing and identification resources (i.e. Identifiers (ID)) within the digital cellular telecommunications system and the 3GPP system. IDs that are covered by this specification includes both public IDs, private IDs and IDs that are assigned to MSs/UEs. Many of the IDs are used temporary in the networks and are allocated and assigned by the operators and some other IDs are allocated and assigned on either global, regional and national level by an administrator.<br />
<br />
[[My 3GPP TS 23.003 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23228.htm 23.228]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 16)<br />
|| This document defines the stage-2 service description for the IP Multimedia Core Network Subsystem (IMS), which includes the elements necessary to support IP Multimedia (IM) services. [[My 3GPP TS 23.228 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)<br />
|| The document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1014 24.007]<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Mobile radio interface signalling layer 3;<br />
General aspects<br />
(Release 17)<br />
| 24.007 document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the basic message format and error handling applied by the layer 3 protocols.<br />
This document also defines the principal architecture of the EPS NAS and 5GS NAS layer 3 protocol and their sublayers, including the message format applied by layer 3.<br />
<br />
[[My 3GPP TS 24.007 Notes]]<br />
|-<br />
| 33.108 || UMTS; LTE; GSM; 3G Security; Handover interface for lawful interception (LI) || [[My TS 133 108 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3182 33.127] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Lawful Interception (LI) architecture and functions<br />
|| This document specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks. The present document provides an LI architecture supporting both network layer based and service layer based Interception. National regulations determine the specific set of LI functional capabilities that are applicable to a specific 3GPP operator deployment.<br />
<br />
[[My 33.127 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3183 33.128] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Protocol and procedures for Lawful Interception (LI);<br />
Stage 3<br />
|| This document specifies the protocols and procedures required to perform Lawful Interception within a 3GPP network. The present document addresses both internal interfaces used internally with a 3GPP network and external handover interfaces used to handover intercepted communications to law enforcement.<br />
<br />
[[My 33.128 Notes]]<br />
|}<br />
<br />
== Standards related info ==<br />
<br />
MCPTT ID parameter is defined in TS 23.280<br />
<br />
[[My ATIS lawful interception standard notes]]<br />
<br />
[[My lawful interception notes]]<br />
<br />
== RFCs of interest ==<br />
<br />
[https://tools.ietf.org/html/rfc3261 RFC 3261 SIP: Session Initiation Protocol]<br />
<br />
[https://tools.ietf.org/html/rfc3455 RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)]<br />
<br />
[https://tools.ietf.org/html/rfc7913 RFC 7913 P-Access-Network-Info ABNF Update]<br />
<br />
[https://tools.ietf.org/html/rfc4984 RFC 4984 Report from the IAB Workshop on Routing and Addressing]<br />
<br />
[https://tools.ietf.org/html/rfc6830 RFC 6830 The Locator/ID Separation Protocol (LISP)]<br />
<br />
== National Requirements Resources ==<br />
<br />
[https://www.bundesnetzagentur.de/EN/Areas/Telecommunications/Companies/ServicerProviderObligation/PublicSafety/Intercepts/start.html German ], see TR TKÜV. See [[My German LI notes]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Shell_Commands&diff=3068Shell Commands2024-01-09T15:20:14Z<p>Paul: /* Networking */</p>
<hr />
<div>== Check Linux Version ==<br />
<br />
Determine kernel version:<br />
<pre>uname -r</pre><br />
<br />
Determine distribution version:<br />
<pre>cat /etc/issue</pre><br />
<br />
== Script command sessions ==<br />
<br />
To log your terminal sessions used <code>script</code> command:<br />
<pre><br />
$script /tmp/terminal.log<br />
</pre><br />
<br />
CTRL+D to end script logging.<br />
<br />
Courtesy of [http://www.unixtutorial.org/2007/11/script-save-your-session-log/ Unix Tutorial site]<br />
<br />
== Regular Expressions ==<br />
<br />
[http://gnosis.cx/publish/programming/regular_expressions.html Regular expressions tutorial]<br />
<br />
[http://etext.lib.virginia.edu/services/helpsheets/unix/regex.html Using regular expressions]<br />
<br />
== vi ==<br />
<br />
[[vi|My vi notes]]<br />
<br />
[http://www.cs.colostate.edu/helpdocs/vi.html vi text editor]<br />
<br />
== Secure Copy (SCP) ==<br />
<br />
Copy file "example.txt" from a remote host to local host<br />
<br />
<pre>$ scp username@remotehost.com:example.txt /local/host/directory</pre><br />
<br />
Example copying remote file to local home directory:<br />
<pre>$ scp -p username@10.0.0.200:/home/username/pkginfo_160209.txt ~/<br />
Password: <br />
pkginfo_160209.txt 100% 101KB 101.0KB/s 00:00</pre><br />
<br />
Copy file "example.txt" from local host to a remote host<br />
<br />
<pre>$ scp example.txt username@remotehost.com:/remote/host/directory</pre><br />
<br />
Copy directory "dirLocal" from local host to remote host's directory "dirRemote"<br />
<br />
<pre>$ scp -r dirLocal username@remotehost.com:/remote/host/directory/dirRemote</pre><br />
<br />
Copy file "example.txt" from remote host "remote1.com" to remote host "remote2.com"<br />
<br />
<pre>$ scp username@remote1.com:/remote/host/directory/example.txt \<br />
username@remote2.com:/remote/host/directory/</pre><br />
<br />
== sed ==<br />
<br />
Print text from line 1024 to line 1034 to console<br />
<br />
<code>sed -n 1024,1034p textFile</code><br />
<br />
Store same text to file<br />
<br />
<code>sed -n 1024,1034p textFile > newTextFile</code><br />
<br />
<br />
== [http://www.gnu.org/software/tar/ Tape Archival (tar)] & [http://www.gzip.org/ gzip] ==<br />
<br />
=== Create tar ===<br />
<br />
<code>tar -cvf filename.tar filemane</code><br />
<br />
=== Undo tar ===<br />
<br />
<code>tar -xvf filename.tar</code><br />
<br />
=== List contents tar ===<br />
<br />
<code>tar -tvf filename.tar</code><br />
<br />
=== Compress file ===<br />
<br />
<code>gzip -9 filename</code><br />
<br />
=== Decompress file ===<br />
<br />
<code>gzip -d filename</code><br />
<br />
=== TAR and compress simultaneously ===<br />
<br />
<code>tar -cvzf newFileName.tar.gz fileOrDirectorToArchiveAndCompress</code><br />
<br />
=== un-TAR and decompress simultaneously ===<br />
<code>tar xvfz fileName.targz</code><br />
<br />
== RAR ==<br />
<br />
Install unrar utility<br />
<br />
<code>sudo apt-get install unrar</code><br />
<br />
Extract files with full path. <br />
<br />
<code>unrar x filename.rar</code><br />
<br />
== Download files ==<br />
<br />
To download type <code>wget</code> then location of file.<br />
<br />
=== Check file integrity ===<br />
<br />
Check MD5 checksum by using <code>md5sum filename</code> then compare checksum.<br />
<br />
Check SHA1 checksum by using <code>sha1sum filename</code> then compare checksum.<br />
<br />
== ifconfig ==<br />
<br />
To determine your IP address settings run:<br />
<br />
<code>ifconfig</code><br />
<br />
== Searching ==<br />
<br />
To find path to a file run:<br />
<br />
<code># find / -name "filename"</code><br />
<br />
To find an expression within a file:<br />
<br />
[http://www.64bitjungle.com/ubuntu/search-file-contents-in-multiple-directories-with-recursive-grep/ tips using grep]<br />
<br />
== List open files ==<br />
<br />
[http://linux.about.com/library/cmd/blcmdl8_lsof.htm List Open Files]<br />
<br />
For example:<br />
<pre>lsof -i tcp:80</pre><br />
<br />
== Comparing files ==<br />
<br />
[http://www.cyberciti.biz/faq/how-do-i-compare-two-files-under-linux-or-unix/ How do I compare two files under linux or unix]<br />
<br />
== Customize BASH prompt ==<br />
<br />
[http://www.lifeaftercoffee.com/2006/10/31/customize-your-bash-prompt/ Customize your bash prompt] basics<br />
<br />
== Networking ==<br />
<br />
[http://www.cyberciti.biz/howto/question/man/tcpdump-man-page-with-examples.php tcpdump] man page with examples<br />
<br />
<pre>sudo tcpdump -D (list interfaces)<br />
<br />
(end with Ctrl+C)<br />
<br />
-i (interface, use 'any' for all)<br />
<br />
-n (disable name resolution)<br />
-nn (disable name resolution and port resolution)<br />
<br />
-T radius <br />
-T vxlan<br />
<br />
-A (Print each packet (minus its link level header) in ASCII. Handy for capturing web pages.)<br />
<br />
-v (-vv or -vvv, verbose mode) <br />
<br />
udp<br />
<br />
sudo tcpdump -i <interface_name> udp and port <port #> -s0 -vv -X (what is S)<br />
<br />
-s (snaplen) Snarf snaplen bytes of data from each packet rather than the default of 262144 bytes.<br />
<br />
-X When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex and ASCII. This is very handy for analysing new protocols. In the current implementation this flag may have the same effect as -XX if the packet is truncated.<br />
<br />
-XX When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex and ASCII.</pre><br />
<br />
[https://www.commandlinefu.com/commands/view/4371/see-entire-packet-payload-using-tcpdump See entire packet payload using tcpdump]<br />
<br />
=== Firewall ===<br />
<br />
[http://www.cyberciti.biz/faq/rhel-fedorta-linux-iptables-firewall-configuration-tutorial/ iptables firewall configuration tutorial]<br />
<br />
Linux Home Networking [http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables Linux Firewalls Using iptables]<br />
<br />
== Tips ==<br />
<br />
Find version of OS<br />
<br />
<code>cat /etc/redhat-release</code><br />
<br />
<code>cat /etc/redhat-release</code><br />
<br />
<code>cat /etc/fedora-release</code><br />
<br />
<code>cat /etc/SuSE-release</code><br />
<br />
=== Password protect with Apache ===<br />
<br />
[http://www.elated.com/articles/password-protecting-your-pages-with-htaccess/ Password protect your pages with htaccess]<br />
<br />
=== Find hostname ===<br />
<br />
Use hostname command without arguments<br />
<br />
== Users and Groups ==<br />
<br />
[http://www.ahinc.com/linux101/users.htm Users]<br />
<br />
[http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/getting-started-guide/s1-navigating-ownership.html Permissions]<br />
<br />
== Hardware ==<br />
<br />
=== Graphics card ===<br />
<br />
Determine your graphic card run lspci command and find line that contains VGA compatible:<br />
<pre>[paul@templar ~]$ lspci<br />
00:00.0 Host bridge: nVidia Corporation C55 Host Bridge (rev a2)<br />
00:00.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:00.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:00.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:00.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:00.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a2)<br />
00:00.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:00.7 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:01.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:02.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:02.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:02.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)<br />
00:03.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)<br />
00:06.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)<br />
00:07.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)<br />
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)<br />
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)<br />
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)<br />
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)<br />
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)<br />
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)<br />
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)<br />
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)<br />
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)<br />
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)<br />
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)<br />
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)<br />
01:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GT] (rev a2)<br />
[paul@templar ~]$</pre><br />
<br />
== Useful sites ==<br />
<br />
[http://www.hypexr.org/linux_scp_help.php Linux SCP help]<br />
<br />
[http://www.commandlinefu.com/commands/browse Command Line Fu] as in Kung "Fu"<br />
<br />
[http://bashcurescancer.com/ BASH cures cancer]<br />
<br />
<center>[[Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Avorion_Info&diff=3067My Avorion Info2023-12-09T19:28:16Z<p>Paul: /* Install Avorion headless server application */</p>
<hr />
<div>== Avorion headless server ==<br />
<br />
These steps were created using Ubuntu 20.04.6 LTS and Avorion server 2.3.1.<br />
<br />
Steps<br />
# Ensure that SteamCMD is installed. The steps to install are [https://developer.valvesoftware.com/wiki/SteamCMD here].<br />
# Create a directory for Avorion headless server application.<br />
# Create a directory for Avorion galaxy files.<br />
# Install Avorion headless server application.<br />
# Start, Save, and Stop Avorion headless server application.<br />
# Update Avorion headless server application.<br />
<br />
For all the steps use your Steam user created for steamcmd. My user is called 'steamy' and the command used to switch to user steamy is:<br />
<br />
<code>$ sudo -u steamy -s</code><br />
<br />
=== Installing Avorion via steamcmd ===<br />
<br />
'''Ensure steamcmd is installed.'''<br />
<br />
=== Create directory for Avorion headless server application ===<br />
<br />
I created a directory called Avorion in the user steamy home directory. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion</code><br />
<br />
=== Create a directory for Avorion galaxy files ===<br />
<br />
I created a directory called Avorion_Galaxies in the user steamy home directory for Avorion headless server app galaxies. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion_Galaxies</code><br />
<br />
=== Install Avorion headless server application ===<br />
<br />
Command format:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir <SERVER_PATH> +app_update 565060 validate +exit</code><br />
<br />
The SERVER_PATH is the absolute path to Avorion headless server application files. The SERVER_PATH for my steps is /home/steamy/Avorion. Command used:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
OR<br />
<br />
If /usr/games not listed in your $PATH variable:<br />
<br />
<code>/usr/games/steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code> <br />
<br />
Result:<br />
<br />
<pre>steamy@ox:~$ /usr/games/steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit<br />
ln: failed to create symbolic link '/home/steamy/.steam/root': No such file or directory<br />
ln: failed to create symbolic link '/home/steamy/.steam/steam': No such file or directory<br />
Redirecting stderr to '/home/steamy/Steam/logs/stderr.txt'<br />
Logging directory: '/home/steamy/Steam/logs'<br />
/tmp/dumps is not owned by us - delete and recreate<br />
Unable to delete /tmp/dumps. Continuing anyway.<br />
[ 0%] Checking for available updates...<br />
[----] Verifying installation...<br />
Steam Console Client (c) Valve Corporation - version 1701290101<br />
-- type 'quit' to exit --<br />
Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory<br />
OK<br />
<br />
Connecting anonymously to Steam Public...OK<br />
Waiting for client config...OK<br />
Waiting for user info...OK<br />
Please use force_install_dir before logon!<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x61) downloading, progress: 18.44 (33554432 / 181982809)<br />
Update state (0x61) downloading, progress: 44.64 (81240693 / 181982809)<br />
Update state (0x61) downloading, progress: 60.77 (110590739 / 181982809)<br />
Update state (0x61) downloading, progress: 86.17 (156816985 / 181982809)<br />
Update state (0x81) verifying update, progress: 13.83 (25165824 / 181982809)<br />
Success! App '565060' fully installed.<br />
steamy@ox:~$</pre><br />
<br />
=== Start, Save, and Stop Avorion headless server application ===<br />
<br />
Command:<br />
<br />
<code>./server.sh --galaxy-name <GALAXY_NAME> --admin <64-bit SteamID> --datapath <GALAXY_PATH></code><br />
<br />
GALAXY_NAME is the name of your galaxy. For this setup, I used <code>Andromedia</code>. <span style="color:red">NOTE: If the GALAXY_NAME doesn't exist, this command will create a galaxy with the GALAXY_NAME value.</span><br />
64-bit SteamID is your 64-bit SteamID. For this setup, use your own 64-bit SteamID.<br />
GALAXY_PATH is the directory where you will store your galaxies. I used <code>/home/steamy/Avorion_Galaxies/</code>.<br />
<br />
Command used without my SteamID:<br />
<br />
<code>./server.sh --galaxy-name Andromeda --admin <64-bit SteamID> --datapath /home/steamy/Avorion_Galaxies/</code><br />
<br />
Once your Avorion headless server application is running, type <code>/save</code> to save galaxy or <code>/stop</code> to exit application. <span style="color:blue">It is good practice to always use /save and then /stop.</span><br />
<br />
<span style="color:red">NOTE: Always stop the server by using <code>/stop</code> command. Closing the console window may cause issues with your galaxy or Avorion headless server application files.</span><br />
<br />
=== Configure Avorion headless server galaxy ===<br />
<br />
[[Avorion server.ini README contents]]<br />
<br />
Make any changes to your server.ini you need by editing the server.ini of your galaxy. It is stored at <GALAXY_PATH>/<GALAXY_NAME>. Save the file after making any changes.<br />
<br />
[[Default Avorion server.ini contents]] for Andromedia galaxy created in previous steps.<br />
<br />
Suggest making a backup of server.ini before making changes!<br />
<br />
=== Update Avorion headless server application ===<br />
<br />
To update your Avorion headless server application, run the same command used to install the application.<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
== Avorion game info ==<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Avorion_Info&diff=3066My Avorion Info2023-12-09T19:27:22Z<p>Paul: /* Install Avorion headless server application */</p>
<hr />
<div>== Avorion headless server ==<br />
<br />
These steps were created using Ubuntu 20.04.6 LTS and Avorion server 2.3.1.<br />
<br />
Steps<br />
# Ensure that SteamCMD is installed. The steps to install are [https://developer.valvesoftware.com/wiki/SteamCMD here].<br />
# Create a directory for Avorion headless server application.<br />
# Create a directory for Avorion galaxy files.<br />
# Install Avorion headless server application.<br />
# Start, Save, and Stop Avorion headless server application.<br />
# Update Avorion headless server application.<br />
<br />
For all the steps use your Steam user created for steamcmd. My user is called 'steamy' and the command used to switch to user steamy is:<br />
<br />
<code>$ sudo -u steamy -s</code><br />
<br />
=== Installing Avorion via steamcmd ===<br />
<br />
'''Ensure steamcmd is installed.'''<br />
<br />
=== Create directory for Avorion headless server application ===<br />
<br />
I created a directory called Avorion in the user steamy home directory. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion</code><br />
<br />
=== Create a directory for Avorion galaxy files ===<br />
<br />
I created a directory called Avorion_Galaxies in the user steamy home directory for Avorion headless server app galaxies. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion_Galaxies</code><br />
<br />
=== Install Avorion headless server application ===<br />
<br />
Command format:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir <SERVER_PATH> +app_update 565060 validate +exit</code><br />
<br />
The SERVER_PATH is the absolute path to Avorion headless server application files. The SERVER_PATH for my steps is /home/steamy/Avorion. Command used:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
OR<br />
<br />
If /usr/games not listed in your $PATH variable:<br />
<br />
<code>/usr/games/steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code> <br />
<br />
Result:<br />
<br />
<pre>steamy@steamnuc00:~$ steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit<br />
Redirecting stderr to '/home/steamy/.steam/logs/stderr.txt'<br />
[ 0%] Checking for available updates...<br />
[----] Verifying installation...<br />
Steam Console Client (c) Valve Corporation - version 1691628584<br />
-- type 'quit' to exit --<br />
Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory<br />
OK<br />
<br />
Connecting anonymously to Steam Public...OK<br />
Waiting for client config...OK<br />
Waiting for user info...OK<br />
Please use force_install_dir before logon!<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x61) downloading, progress: 4.61 (6291456 / 136420041)<br />
Update state (0x61) downloading, progress: 27.83 (37970732 / 136420041)<br />
Update state (0x61) downloading, progress: 50.12 (68379436 / 136420041)<br />
Update state (0x61) downloading, progress: 70.63 (96351157 / 136420041)<br />
Update state (0x61) downloading, progress: 93.85 (128031433 / 136420041)<br />
Success! App '565060' fully installed.<br />
CWorkThreadPool::~CWorkThreadPool: work processing queue not empty: 1 items discarded.<br />
steamy@steamnuc00:~$</pre><br />
<br />
=== Start, Save, and Stop Avorion headless server application ===<br />
<br />
Command:<br />
<br />
<code>./server.sh --galaxy-name <GALAXY_NAME> --admin <64-bit SteamID> --datapath <GALAXY_PATH></code><br />
<br />
GALAXY_NAME is the name of your galaxy. For this setup, I used <code>Andromedia</code>. <span style="color:red">NOTE: If the GALAXY_NAME doesn't exist, this command will create a galaxy with the GALAXY_NAME value.</span><br />
64-bit SteamID is your 64-bit SteamID. For this setup, use your own 64-bit SteamID.<br />
GALAXY_PATH is the directory where you will store your galaxies. I used <code>/home/steamy/Avorion_Galaxies/</code>.<br />
<br />
Command used without my SteamID:<br />
<br />
<code>./server.sh --galaxy-name Andromeda --admin <64-bit SteamID> --datapath /home/steamy/Avorion_Galaxies/</code><br />
<br />
Once your Avorion headless server application is running, type <code>/save</code> to save galaxy or <code>/stop</code> to exit application. <span style="color:blue">It is good practice to always use /save and then /stop.</span><br />
<br />
<span style="color:red">NOTE: Always stop the server by using <code>/stop</code> command. Closing the console window may cause issues with your galaxy or Avorion headless server application files.</span><br />
<br />
=== Configure Avorion headless server galaxy ===<br />
<br />
[[Avorion server.ini README contents]]<br />
<br />
Make any changes to your server.ini you need by editing the server.ini of your galaxy. It is stored at <GALAXY_PATH>/<GALAXY_NAME>. Save the file after making any changes.<br />
<br />
[[Default Avorion server.ini contents]] for Andromedia galaxy created in previous steps.<br />
<br />
Suggest making a backup of server.ini before making changes!<br />
<br />
=== Update Avorion headless server application ===<br />
<br />
To update your Avorion headless server application, run the same command used to install the application.<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
== Avorion game info ==<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Byobu_notes&diff=3065My Byobu notes2023-12-09T18:45:53Z<p>Paul: /* Verify or install Byobu */</p>
<hr />
<div>== Byobu notes ==<br />
<br />
These notes were originally taken while using Ubuntu Desktop 18.04.1 LTS.<br />
<br />
Some notes were updated with Ubuntu Server 22.04.3.<br />
<br />
=== Byobu resources ===<br />
<br />
[https://www.digitalocean.com/community/tutorials/how-to-install-and-use-byobu-for-terminal-management-on-ubuntu-16-04 How to install and use Byobu for terminal management] on Ubuntu 16-04.<br />
<br />
== Verify or install Byobu ==<br />
<br />
Verify whether Byobu is installed<br />
<br />
<pre>$ byobu --version<br />
byobu version 5.125<br />
tmux 2.6</pre><br />
<br />
or with Ubuntu Server 22 (in December 2023):<br />
<br />
<pre>$ byobu --version<br />
byobu version 5.133<br />
tmux 3.2a</pre><br />
<br />
If you do not get a version install Byobu with <code>sudo apt-get install byobu</code><br />
<br />
== Start Byobu at login ==<br />
<br />
You can start Byobu manually every time you want to use Byobu or automatically at login.<br />
<br />
To manually start Byobu type <code>byobu</code> at prompt.<br />
<br />
To automatically start at login type <code>byobu-enable</code> at prompt.<br />
<br />
<pre>$ byobu-enable<br />
<br />
The Byobu window manager will be launched automatically at each text login.<br />
<br />
To disable this behavior later, just run:<br />
byobu-disable<br />
</pre><br />
<br />
If you want to disable automatic use of Byobu type <code>byobu-disable</code> at prompt.<br />
<br />
== Byobu help ==<br />
<br />
Press Shift + F1.<br />
<br />
Current help output<br />
<pre>Byobu is a suite of enhancements to tmux, as a command line<br />
tool providing live system status, dynamic window management,<br />
and some convenient keybindings:<br />
<br />
F1 * Used by X11 *<br />
Shift-F1 Display this help<br />
F2 Create a new window<br />
Shift-F2 Create a horizontal split<br />
Ctrl-F2 Create a vertical split<br />
Ctrl-Shift-F2 Create a new session<br />
F3/F4 Move focus among windows<br />
Alt-Left/Right Move focus among windows<br />
Alt-Up/Down Move focus among sessions<br />
Shift-Left/Right/Up/Down Move focus among splits<br />
Shift-F3/F4 Move focus among splits<br />
Ctrl-F3/F4 Move a split<br />
Ctrl-Shift-F3/F4 Move a window<br />
Shift-Alt-Left/Right/Up/Down Resize a split<br />
F5 Reload profile, refresh status<br />
Alt-F5 Toggle UTF-8 support, refresh status<br />
Shift-F5 Toggle through status lines<br />
Ctrl-F5 Reconnect ssh/gpg/dbus sockets<br />
Ctrl-Shift-F5 Change status bar's color randomly<br />
F6 Detach session and then logout<br />
Shift-F6 Detach session and do not logout<br />
Alt-F6 Detach all clients but yourself<br />
Ctrl-F6 Kill split in focus<br />
F7 Enter scrollback history<br />
Alt-PageUp/PageDown Enter and move through scrollback<br />
Shift-F7 Save history to $BYOBU_RUN_DIR/printscreen<br />
F8 Rename the current window<br />
Ctrl-F8 Rename the current session<br />
Shift-F8 Toggle through split arrangements<br />
Alt-Shift-F8 Restore a split-pane layout<br />
Ctrl-Shift-F8 Save the current split-pane layout<br />
F9 Launch byobu-config window<br />
Ctrl-F9 Enter command and run in all windows<br />
Shift-F9 Enter command and run in all splits<br />
Alt-F9 Toggle sending keyboard input to all splits<br />
F10 * Used by X11 *<br />
F11 * Used by X11 *<br />
Alt-F11 Expand split to a full window<br />
Shift-F11 Zoom into a split, zoom out of a split<br />
Ctrl-F11 Join window into a vertical split<br />
F12 Escape sequence<br />
Shift-F12 Toggle on/off Byobu's keybindings<br />
Alt-F12 Toggle on/off Byobu's mouse support<br />
Ctrl-Shift-F12 Mondrian squares<br />
(END)</pre><br />
<br />
== Using Byobu ==<br />
<br />
Put tmux status bar on top of terminal window. Modify or create file ~/.byobu/.tmux.conf and put these commands in file:<br />
<br />
<pre>set -g status-position top</pre><br />
<br />
<br />
<br />
<center>[[Linux|To Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Byobu_notes&diff=3064My Byobu notes2023-12-09T18:25:53Z<p>Paul: /* Byobu notes */</p>
<hr />
<div>== Byobu notes ==<br />
<br />
These notes were originally taken while using Ubuntu Desktop 18.04.1 LTS.<br />
<br />
Some notes were updated with Ubuntu Server 22.04.3.<br />
<br />
=== Byobu resources ===<br />
<br />
[https://www.digitalocean.com/community/tutorials/how-to-install-and-use-byobu-for-terminal-management-on-ubuntu-16-04 How to install and use Byobu for terminal management] on Ubuntu 16-04.<br />
<br />
== Verify or install Byobu ==<br />
<br />
Verify whether Byobu is installed<br />
<br />
<pre>$ byobu --version<br />
byobu version 5.125<br />
tmux 2.6</pre><br />
<br />
If you do not get a version install Byobu with <code>sudo apt-get install byobu</code><br />
<br />
== Start Byobu at login ==<br />
<br />
You can start Byobu manually every time you want to use Byobu or automatically at login.<br />
<br />
To manually start Byobu type <code>byobu</code> at prompt.<br />
<br />
To automatically start at login type <code>byobu-enable</code> at prompt.<br />
<br />
<pre>$ byobu-enable<br />
<br />
The Byobu window manager will be launched automatically at each text login.<br />
<br />
To disable this behavior later, just run:<br />
byobu-disable<br />
</pre><br />
<br />
If you want to disable automatic use of Byobu type <code>byobu-disable</code> at prompt.<br />
<br />
== Byobu help ==<br />
<br />
Press Shift + F1.<br />
<br />
Current help output<br />
<pre>Byobu is a suite of enhancements to tmux, as a command line<br />
tool providing live system status, dynamic window management,<br />
and some convenient keybindings:<br />
<br />
F1 * Used by X11 *<br />
Shift-F1 Display this help<br />
F2 Create a new window<br />
Shift-F2 Create a horizontal split<br />
Ctrl-F2 Create a vertical split<br />
Ctrl-Shift-F2 Create a new session<br />
F3/F4 Move focus among windows<br />
Alt-Left/Right Move focus among windows<br />
Alt-Up/Down Move focus among sessions<br />
Shift-Left/Right/Up/Down Move focus among splits<br />
Shift-F3/F4 Move focus among splits<br />
Ctrl-F3/F4 Move a split<br />
Ctrl-Shift-F3/F4 Move a window<br />
Shift-Alt-Left/Right/Up/Down Resize a split<br />
F5 Reload profile, refresh status<br />
Alt-F5 Toggle UTF-8 support, refresh status<br />
Shift-F5 Toggle through status lines<br />
Ctrl-F5 Reconnect ssh/gpg/dbus sockets<br />
Ctrl-Shift-F5 Change status bar's color randomly<br />
F6 Detach session and then logout<br />
Shift-F6 Detach session and do not logout<br />
Alt-F6 Detach all clients but yourself<br />
Ctrl-F6 Kill split in focus<br />
F7 Enter scrollback history<br />
Alt-PageUp/PageDown Enter and move through scrollback<br />
Shift-F7 Save history to $BYOBU_RUN_DIR/printscreen<br />
F8 Rename the current window<br />
Ctrl-F8 Rename the current session<br />
Shift-F8 Toggle through split arrangements<br />
Alt-Shift-F8 Restore a split-pane layout<br />
Ctrl-Shift-F8 Save the current split-pane layout<br />
F9 Launch byobu-config window<br />
Ctrl-F9 Enter command and run in all windows<br />
Shift-F9 Enter command and run in all splits<br />
Alt-F9 Toggle sending keyboard input to all splits<br />
F10 * Used by X11 *<br />
F11 * Used by X11 *<br />
Alt-F11 Expand split to a full window<br />
Shift-F11 Zoom into a split, zoom out of a split<br />
Ctrl-F11 Join window into a vertical split<br />
F12 Escape sequence<br />
Shift-F12 Toggle on/off Byobu's keybindings<br />
Alt-F12 Toggle on/off Byobu's mouse support<br />
Ctrl-Shift-F12 Mondrian squares<br />
(END)</pre><br />
<br />
== Using Byobu ==<br />
<br />
Put tmux status bar on top of terminal window. Modify or create file ~/.byobu/.tmux.conf and put these commands in file:<br />
<br />
<pre>set -g status-position top</pre><br />
<br />
<br />
<br />
<center>[[Linux|To Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_TS_103_221-2_notes&diff=3063My TS 103 221-2 notes2023-11-13T18:27:45Z<p>Paul: initial page creation</p>
<hr />
<div>My notes using ETSI TS 103 221-2 V1.6.1 (2022-03)<br />
<br />
== 4 Introduction and reference model ==<br />
<br />
=== 4.1 Reference model ===<br />
<br />
[[File:103 221-2-reference-model.png]]<br />
<br />
<center>[[Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=File:103_221-2-reference-model.png&diff=3062File:103 221-2-reference-model.png2023-11-13T18:26:32Z<p>Paul: TS 103 221-2 § 4.1 reference model</p>
<hr />
<div>== Summary ==<br />
TS 103 221-2 § 4.1 reference model</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Telecommunications_info&diff=3061Telecommunications info2023-11-13T17:29:07Z<p>Paul: /* Lawful Interception Standards */</p>
<hr />
<div>== NNI Task Force ==<br />
<br />
[https://www.sipforum.org/activities/nni-task-force-introduction/ NNI Task Force Introduction]<br />
<br />
== 3GPP SA3 Security ==<br />
<br />
[https://www.3gpp.org/specifications-groups/sa-plenary/sa3-security SA3 - Security]<br />
<br />
== [https://www.3gpp.org/specifications/79-specification-numbering 3GPP Standards] ==<br />
<br />
[https://www.3gpp.org/specifications/79-specification-numbering 3GPP specification numbering]<br />
<br />
[https://www.3gpp.org/DynaReport/status-report.htm 3GPP Specification Status Report]<br />
<br />
=== Definition and abbreviations ===<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
=== EPS and NR related standards with notes ===<br />
<br />
[[My New Radio (NR) notes]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Standard # !! Title !! Notes<br />
|-<br />
| 22.011<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service accessibility<br />
| The purpose of 22.011 is to describe the service access procedures as presented to the user. Definitions and procedures are provided in 22.011 for international roaming, national roaming and regionally provided service. These are mandatory in relation to the technical realization of the Mobile Station, or User Equipment (UE).<br />
<br />
[[My 3GPP TS 22.011 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/22261.htm 22.261] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Service requirements for the 5G system;<br />
Stage 1<br />
|| Document describes the service and operational requirements for a 5G system, including a UE, NG-RAN, and 5G Core network. Requirements for a 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC are found in TS 22.278.<br />
|-<br />
| 23.122 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode<br />
|| Document gives an overview of the tasks undertaken by the Core network protocols of a Mobile Station (MS) when in idle mode, that is, switched on but typically not having a dedicated channel allocated. It also describes the corresponding network functions. The conditions when the idle mode functions are performed by an MS in the UTRA RRC connected mode states are specified in 3GPP TS 25.331. The conditions when the idle mode functions are performed by an MS in the E-UTRAN are specified in 3GPP TS 36.304. <span style="color:blue">The conditions when the idle mode functions are performed by an MS in the NG-RAN are specified in 3GPP TS 36.304 and 3GPP TS 38.304. The conditions when the idle mode functions are performed by an MS in the NG-RAN RRC inactive state are specified in 3GPP TS 36.331 and 3GPP TS 38.331</span>.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23271.htm 23.271] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Functional stage 2 description of Location Services (LCS)<br />
(Release 16)<br />
|| Document specifies the stage 2 of the LoCation Services (LCS) feature in UMTS, GSM and EPS (for E-UTRAN), which provides the mechanisms to support mobile location services for operators, subscribers and third party service providers. Location Services in 5GC are restricted to regulatory services and are specified in TS 23.501 and TS 23.502 in this release of the specification. The architecture and signalling procedures in NG-RAN are defined in TS 38.305.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3577 23.273] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
5G System (5GS) Location Services (LCS);<br />
Stage 2<br />
|| V17.5.0 document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
General Packet Radio Service (GPRS) enhancements for<br />
Evolved Universal Terrestrial Radio Access Network<br />
(E-UTRAN) access<br />
(Release 17)<br />
|| This document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).<br />
The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 23.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
System architecture for the 5G System (5GS);<br />
Stage 2<br />
|| 5G core network [[My 3GPP 23.501 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145 23.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Procedures for the 5G System (5GS);<br />
Stage 2<br />
| V17.5.0 document defines the Stage 2 procedures and Network Function Services for the 5G system architecture which is described in the TS 23.501 and for the policy and charging control framework which is described in TS 23.503.<br />
<br />
[[My 3GPP 23.502 Notes]]<br />
|-<br />
| 24.229 || Digital cellular telecommunications system (Phase 2+) (GSM);<br>Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);<br>Stage 3 || P-Access-Network-Info values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto" and "gstn-location" are defined in section 7.2A.4<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370 24.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Non-Access-Stratum (NAS) protocol for 5G System (5GS);<br />
Stage 3;<br />
|| This present document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
[[My 3GPP 24.501 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3371 24.502] || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Access to the 3GPP 5G Core Network (5GCN)<br />
via Non-3GPP Access Networks (N3AN);<br />
Stage 3<br />
|| This document specifies non-3GPP access network discovery and selection procedures, the access authorization procedure used for accessing non-3GPP access networks. These non-3GPP access networks can be trusted non-3GPP access networks, untrusted non-3GPP access networks or wireline access networks.<br />
|-<br />
| 29.503 || 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
5G System; Unified Data Management Services;<br />
Stage 3<br />
|| The document specifies the stage 3 protocol and data model for the Nudm Service Based Interface. It provides stage 3 protocol definitions and message flows, and specifies the API for each service offered by the UDM.<br />
<br />
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 and 3GPP TS 23.502.<br />
<br />
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition are specified in 3GPP TS 29.500 and 3GPP TS 29.501.<br />
|-<br />
| 29.279 || Universal Mobile Telecommunications System (UMTS);<br>LTE;<br>Mobile IPv4 (MIPv4) based mobility protocols;<br>Stage 3 ||<br />
|-<br />
| [https://www.3gpp.org/DynaReport/29571.htm 29.571] || 5G System; Common Data Types for Service Based Interfaces; Stage 3 || The document specifies the stage 3 protocol and data model for common data types that are used or may be expected to be used by multiple Service Based Interface APIs supported by the same or different Network Function(s).<br />
|-<br />
| [https://www.3gpp.org/DynaReport/33501.htm 33.501] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security architecture and procedures for 5G system<br />
|| Document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
[[My 3GPP 33.501 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/37340.htm 37.340] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
Evolved Universal Terrestrial Radio Access (E-UTRA) and NR;<br />
Multi-connectivity;<br />
Stage 2<br />
|| Document provides an overview of the multi-connectivity operation using E-UTRA and NR radio access technologies.<br />
|-<br />
| 38.300 || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2<br />
|| This document provides an overview and overall description of the NG-RAN and focuses on the radio interface protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the radio interface protocols are specified in companion specifications of the 38 series.<br />
<br />
[[My 3GPP 38.300 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38304.htm 38.304] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
User Equipment (UE) procedures in Idle mode and RRC Inactive state<br />
|| Document specifies the Access Stratum (AS) part of the UE procedures in RRC_IDLE state (also called Idle mode) and RRC_INACTIVE state. The non-access stratum (NAS) part of Idle mode procedures and processes is specified in TS 23.122.<br />
<br />
[[My 3GPP TS 38.304 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197 38.331] || 3rd Generation Partnership Project;<br />
Technical Specification Group Radio Access Network;<br />
NR;<br />
Radio Resource Control (RRC) protocol specification<br />
(Release 17)<br />
|| This document specifies the Radio Resource Control protocol for the radio interface between UE and NG-RAN.<br />
|-<br />
| [https://www.3gpp.org/DynaReport/38401.htm 38.401] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description || Document describes the overall architecture of the NG-RAN, including interfaces NG, Xn and F1 interfaces and their interaction with the radio interface.<br />
<br />
[[My 3GPP TS 38.401 Notes]] <br />
|-<br />
| [https://www.3gpp.org/DynaReport/38413.htm 38.413] || 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)(Release 16) || This document specifies the radio network layer signalling protocol for the NG interface. The NG Application Protocol (NGAP) supports the functions of the NG interface by signalling procedures defined in this document. NGAP is developed in accordance to the general principles stated in TS 38.401 and TS 38.410.<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|-<br />
| Example || Example || Example<br />
|}<br />
<br />
== 3GPP/ETSI info ==<br />
<br />
[https://www.etsi.org/technologies/5g ETSI 5G information page]<br />
<br />
[https://www.etsi.org/technologies/lawful-interception ETSI Lawful Interception (LI) information page]<br />
<br />
[https://www.etsi.org/committee/1403-li ETSI Technical Committee (TC) Lawful Interception information page] and contains list of latest publications<br />
<br />
=== [https://www.etsi.org/standards ETSI Standards] ===<br />
<br />
==== Lawful Interception Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! ETSI Standard<br />
! Title<br />
! Notes<br />
|-<br />
| ETSI TS 102 232-1 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery || This document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks. This document:<br />
* specifies the modular approach used for specifying IP based handover interfaces;<br />
* specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;<br />
* specifies protocols for the transfer of IRI and CC across the handover interfaces;<br />
* specifies protocol profiles for the handover interface.<br />
|-<br />
| ETSI TS 102 232-2 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 2: Service-specific details for messaging services || This document contains a stage 1 like description of the interception information in relation to the process of sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain. Examples of asynchronous messages include: email, unified messaging and chat applications. See 102-232-1 for stage 3.<br />
|-<br />
| ETSI TS 102 232-3 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services ||<br />
|-<br />
| ETSI TS 102 232-4 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 4: Service-specific details for Layer 2 services ||<br />
|-<br />
| ETSI TS 102 232-5 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia services ||<br />
|-<br />
| ETSI TS 102 232-6 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services || <br />
|-<br />
| ETSI TS 102 232-7 || Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 7: Service-specific details for Mobile Services ||<br />
|-<br />
| ETSI TS 103 221 || Lawful Interception (LI); Internal Network Interfaces || Part I (X1) and Part II (X2/X3) [[My TS 103 221-2 notes]]<br />
|-<br />
| ETSI TS 103 643 || Techniques for assurance of digital material used in legal proceedings ||<br />
|-<br />
| ETSI TS 101 671 || Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic || Document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is usually mandatory for the operation of any telecommunication service. Step 1 contains the requirements for lawful interception from a users (LEAs) point of view and is published in ETSI TS 101 331. Step 2 describes the derived network functions and the general architecture (or functional model) and is published in ETSI ES 201 158. <br />
|-<br />
| ETSI TS 103 462 || Lawful Interception (LI); Inter LEMF Handover Interface ||<br />
|-<br />
| style="white-space: nowrap;" | ETSI TR 102 503 || Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and Retained data handling Specifications ||<br />
|-<br />
| ETSI TS 102 656 || Lawful Interception (LI); Retained Data; Requirements of Law Enforcement Agencies for handling Retained Data ||<br />
|-<br />
| ETSI TS 102 657 || Lawful Interception (LI); Retained data handling; Handover interface for the request and delivery of retained data ||<br />
|-<br />
| ETSI TS 101 331 || Lawful Interception (LI); Requirements of Law Enforcement Agencies || Document gives guidance for lawful interception of telecommunications in the area of co-operation by network operators, access providers, and service providers. Document describes the requirements from a Law Enforcement Agency's (LEA's) point of view.<br />
|-<br />
| ETSI TS 103 707 || Lawful Interception (LI); Handover for messaging services over HTTP/XML || Document specifies the handover details to deliver messaging services for LI over HTTP/XML<br />
|-<br />
| ETSI TS 103 120 || Lawful Interception (LI); Interface for warrant information || Document defines an electronic interface between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception.<br />
|-<br />
| ETSI TS 103 280 || Lawful Interception (LI); Dictionary for common parameters || Document defines a dictionary of parameters that are commonly used in multiple TC LI specifications. Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use. It is encouraged to use the present document in the development of new specifications. [[My ETSI TS 103 280 notes]]<br />
|-<br />
| ETSI TS 103 690 || Lawful Interception (LI); eWarrant Interface || Document presents a high-level description of an interface mechanism - the eWarrant Interface - for receipt of requests for measures producing real-time or stored information by an issuing authority possessing lawful authorization to initiate such a request<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|-<br />
| || ||<br />
|}<br />
<br />
==== Other Standards ====<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! 3GPP<br />
! Title<br />
! Notes<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729 23.003]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17)<br />
|| This document defines the principal purpose and use of different naming, numbering, addressing and identification resources (i.e. Identifiers (ID)) within the digital cellular telecommunications system and the 3GPP system. IDs that are covered by this specification includes both public IDs, private IDs and IDs that are assigned to MSs/UEs. Many of the IDs are used temporary in the networks and are allocated and assigned by the operators and some other IDs are allocated and assigned on either global, regional and national level by an administrator.<br />
<br />
[[My 3GPP TS 23.003 notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23228.htm 23.228]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 16)<br />
|| This document defines the stage-2 service description for the IP Multimedia Core Network Subsystem (IMS), which includes the elements necessary to support IP Multimedia (IM) services. [[My 3GPP TS 23.228 Notes]]<br />
|-<br />
| [https://www.3gpp.org/DynaReport/23401.htm 23.401]<br />
|| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 16)<br />
|| The document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies, policy control and charging, and authentication.<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1014 24.007]<br />
| 3rd Generation Partnership Project;<br />
Technical Specification Group Core Network and Terminals;<br />
Mobile radio interface signalling layer 3;<br />
General aspects<br />
(Release 17)<br />
| 24.007 document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the basic message format and error handling applied by the layer 3 protocols.<br />
This document also defines the principal architecture of the EPS NAS and 5GS NAS layer 3 protocol and their sublayers, including the message format applied by layer 3.<br />
<br />
[[My 3GPP TS 24.007 Notes]]<br />
|-<br />
| 33.108 || UMTS; LTE; GSM; 3G Security; Handover interface for lawful interception (LI) || [[My TS 133 108 notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3182 33.127] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Lawful Interception (LI) architecture and functions<br />
|| This document specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks. The present document provides an LI architecture supporting both network layer based and service layer based Interception. National regulations determine the specific set of LI functional capabilities that are applicable to a specific 3GPP operator deployment.<br />
<br />
[[My 33.127 Notes]]<br />
|-<br />
| [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3183 33.128] || 3rd Generation Partnership Project;<br />
Technical Specification Group Services and System Aspects;<br />
Security;<br />
Protocol and procedures for Lawful Interception (LI);<br />
Stage 3<br />
|| This document specifies the protocols and procedures required to perform Lawful Interception within a 3GPP network. The present document addresses both internal interfaces used internally with a 3GPP network and external handover interfaces used to handover intercepted communications to law enforcement.<br />
<br />
[[My 33.128 Notes]]<br />
|}<br />
<br />
== Standards related info ==<br />
<br />
MCPTT ID parameter is defined in TS 23.280<br />
<br />
[[My ATIS lawful interception standard notes]]<br />
<br />
[[My lawful interception notes]]<br />
<br />
== RFCs of interest ==<br />
<br />
[https://tools.ietf.org/html/rfc3261 RFC 3261 SIP: Session Initiation Protocol]<br />
<br />
[https://tools.ietf.org/html/rfc3455 RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)]<br />
<br />
[https://tools.ietf.org/html/rfc7913 RFC 7913 P-Access-Network-Info ABNF Update]<br />
<br />
[https://tools.ietf.org/html/rfc4984 RFC 4984 Report from the IAB Workshop on Routing and Addressing]<br />
<br />
[https://tools.ietf.org/html/rfc6830 RFC 6830 The Locator/ID Separation Protocol (LISP)]<br />
<br />
== National Requirements Resources ==<br />
<br />
[https://www.bundesnetzagentur.de/EN/Areas/Telecommunications/Companies/ServicerProviderObligation/PublicSafety/Intercepts/start.html German ], see TR TKÜV. See [[My German LI notes]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Computing&diff=3060Computing2023-11-06T07:04:45Z<p>Paul: /* My regex notes for checking an ASN.1 GeneralizedTime type */</p>
<hr />
<div><big>'''My Computing Area'''</big><br />
<br />
== Personal Computer ==<br />
<br />
[[Personal Computer]] section<br />
<br />
== Web based utiliites ==<br />
<br />
[http://www.network-science.de/ascii/ ASCII generator]<br />
<br />
== Networking ==<br />
<br />
[[Networking]] section<br />
<br />
== Video Games ==<br />
<br />
[[Video Game]]<br />
<br />
== Programming & Scripting ==<br />
<br />
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html TIOBE Programming Community Index]<br />
<br />
[[Jupyter|My Jupyter notes]]<br />
<br />
=== ASN.1 ===<br />
<br />
[[My ASN.1 Notes]]<br />
<br />
=== PHP ===<br />
<br />
[[PHP]]<br />
<br />
=== C++ ===<br />
<br />
[[My C++ Notes]]<br />
<br />
=== C Sharp ===<br />
<br />
[[My C Sharp Notes]]<br />
<br />
[https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/ Parallel programming]<br />
<br />
[http://www.mikeadev.net/2012/07/multi-threaded-tcp-server-in-csharp/ Multi-threaded TCP server in C#]<br />
<br />
=== Eclipse ===<br />
<br />
[[ My Eclipse]] pages<br />
<br />
[http://www.eclipse.org/downloads/ Eclipse] IDE tools<br />
<br />
[http://wiki.eclipse.org/PDT/TUTORIALS Eclipse] tutorials<br />
<br />
=== Python ===<br />
<br />
[[Python|My Python notes]]<br />
<br />
=== Lua ===<br />
<br />
[[My Lua Notes]]<br />
<br />
[http://www.lua.org/ Lua] is a powerful, fast, lightweight, embeddable scripting language.<br />
<br />
=== shell scripting ===<br />
<br />
=== PERL ===<br />
<br />
[[PERL]]<br />
<br />
[http://mojolicio.us/ Mojolicious]<br />
<br />
=== Java ===<br />
<br />
[[My Java Notes]]<br />
<br />
[http://netbeans.org/ NetBeans]<br />
<br />
[http://www.javaworld.com/ JavaWorld] is an ad covered site that offers how-to articles, news stories, and other information on Java development.<br />
<br />
[http://www.developer.com/index.php?/java developer.com] is a source for Java information<br />
<br />
[http://www.jguru.com/index.jsp Java guru] has articles and training material<br />
<br />
=== JavaScript ===<br />
<br />
[[JavaScript]]<br />
<br />
[[My Node.js notes]]<br />
<br />
== APIs ==<br />
<br />
[[My REST API notes]]<br />
<br />
[https://apilayer.com/ apilayer] Automate What Should Be Automated. Unparalleled suite of productivity-boosting Web APIs & cloud-based SaaS Applications for developers and companies of any size.<br />
<br />
[http://restcountries.eu/ REST Countries] Get information about countries via a RESTful API<br />
<br />
=== OpenAPI ===<br />
<br />
[https://app.swaggerhub.com/help/tutorials/index Swagger v2 tutorials]<br />
<br />
[https://app.swaggerhub.com/help/tutorials/openapi-3-tutorial OpenAPI v3 tutorial]<br />
<br />
== Version control systems ==<br />
<br />
'''Pijul'''<br />
<br />
[https://pijul.org/ Pijul] is a free and open source (GPL2) distributed version control system. Its distinctive feature is to be based on a sound theory of patches, which makes it easy to learn and use, and really distributed.<br />
<br />
'''Git'''<br />
<br />
[[My git notes]]<br />
<br />
[http://git-scm.com/doc Git documentation]<br />
<br />
== Database stuff ==<br />
<br />
=== PostgreSQL ===<br />
<br />
[[My PostgreSQL Notes]]<br />
<br />
=== MySQL & MariaDB ===<br />
<br />
[[MySQL| My MySQL & MariaDB Notes]] section (contains some MariaDB stuff)<br />
<br />
<br />
== Regular Expressions ==<br />
<br />
=== Resources ===<br />
<br />
[https://regex101.com/ Regex101] site (very handy online checker and pretty)<br />
[http://regexlib.com/ Regex Library]<br />
<br />
=== IPv4 address examples ===<br />
<pre>^(([1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.)((\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.){2}(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])$</pre><br />
<br />
Some test formats:<br />
<br />
<pre>1.0.0.0 < - matches<br />
<br />
0.0.0.0 <- no match<br />
<br />
1.0.0.255 < - matches<br />
<br />
1.01.0.255 < - no match<br />
<br />
1.255.255.255 < - matches<br />
<br />
1.256.255.255 < - no match<br />
<br />
255.255.255.255 < - matches<br />
<br />
256.255.255.255 < - no match</pre><br />
<br />
==== IPv4 with slash & network mask ====<br />
<pre><br />
^(([1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.)((\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.){2}(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])\/([1-9]|[1-2]\d|3[0-2])$</pre><br />
<br />
Some examples to test:<br />
<pre>1.0.0.0/1 < - matches<br />
1.0.0.255/30 < - matches<br />
1.255.255.255/24 < - matches<br />
255.255.255.255/10 < - matches<br />
1.0.0.0/100 < - matches<br />
1.0.0.255/0 < - no match</pre><br />
<br />
=== IPv6 address examples (hexadecimal formats only) ===<br />
<br />
Long form only:<br />
<br />
<pre>^([0-9a-fA-F]{4}:){7}[0-9a-fA-F]{4}$</pre><br />
<br />
Medium form that allows leading zeros in hextet:<br />
<br />
<pre>^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$</pre><br />
<br />
Medium form that does not allow leading zeros in hextet:<br />
<br />
<pre>^(([0-9a-fA-F]{1}|[1-9a-fA-F]{1}[0-9a-fA-F]{1,3}):){7}([0-9a-fA-F]{1}|[1-9a-fA-F]{1}[0-9a-fA-F]{1,3})$</pre><br />
<br />
Some test formats:<br />
<pre>0:0:0:0:0:0:0:0<br />
<br />
7:6:5:4:3:2:1:0<br />
<br />
ffff:ffff:ffff:ffff:FFFF:FFFF:FFFF:FFFF<br />
<br />
0fff:ffff:ffff:ffff:FFFF:FFFF:FFFF:FFFF (invalid due to leading 0 in first hextet group)</pre><br />
<br />
==== IPv6 with slash & network mask ====<br />
<br />
<pre>(^(([0-9a-fA-F]{4}:){7}[0-9a-fA-F]{4})|(^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}))\/([1-9]|[1-9]\d|1[0-1]\d|12[0-8])$</pre><br />
<br />
Some test formats:<br />
<pre>0:0:0:0:0:0:0:0/69 < - matches<br />
0:0:0:0:0:0:0:0/1 < - matches<br />
7:6:5:4:3:2:1:0/10 < - matches<br />
7:6:5:4:3:2:1:0/99 < - matches<br />
7:6:5:4:3:2:1:0/128 < - matches<br />
7:6:5:4:3:2:1:0/129 < - no match<br />
7:6:5:4:3:2:1:0/0 < - no match<br />
ffff:ffff:ffff:ffff:FFFF:FFFF:FFFF:FFFF/55 < - matches<br />
fff:ffff:ffff:ffff:FFFF:FFFF:FFFF:FFFF/119 < - matches<br />
2001:0db8:0000:0000:0000:ff00:0042:8329/0 < - no match<br />
2001:0db8:0000:0000:0000:ff00:0042:8329/20 < - matches<br />
2001:db8:0:0:0:ff00:42:8329/9 < - matches</pre><br />
<br />
=== IPv4 & IPv6 combined regex ===<br />
<br />
I simply combined the above examples into one pattern that can match various formats. The following pattern matches both IPv4 and IPv6 addresses, both long and medium (allow leading zeros), using single regex:<br />
<br />
<pre>(^(([0-9a-fA-F]{1,4}:){4,7}[0-9a-fA-F]{1,4})$)|(^([0-9a-fA-F]{4}:){7}[0-9a-fA-F]{4}$)|(^(([1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.)((\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.){2}(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])$)</pre><br />
<br />
==== IPv4 and IPv6 network and masks ====<br />
<br />
<pre>(^(([0-9a-fA-F]{1,4}:){4,7}[0-9a-fA-F]{1,4})\/([1-9]|[1-9]\d|1[0-1]\d|12[0-8])$)|(^([0-9a-fA-F]{4}:){7}[0-9a-fA-F]{4}\/([1-9]|[1-9]\d|1[0-1]\d|12[0-8])$)|(^(([1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.)((\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.){2}(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])\/([1-9]|[1-9]\d|1[0-1]\d|12[0-8])$)</pre><br />
<br />
Some examples<br />
<br />
<pre>0:0:0:0:0:0:0:0/1 < - matches<br />
0:0:0:0:0:0:0:0/1 < - matches<br />
7:6:5:4:3:2:1:0/10 < - matches<br />
7:6:5:4:3:2:1:0/99 < - matches<br />
7:6:5:4:3:2:1:0/128 < - matches<br />
7:6:5:4:3:2:1:0/129 < - no match<br />
7:6:5:4:3:2:1:0/0 < - no match<br />
ffff:ffff:ffff:ffff:FFFF:FFFF:FFFF:FFFF/69 < - matches<br />
fff:ffff:ffff:ffff:FFFF:FFFF:FFFF:FFFF/119 < - matches<br />
2001:0db8:0000:0000:0000:ff00:0042:8329/0 < - no match<br />
2001:db8:0:0:0:ff00:42:8329/9 < - matches<br />
1.0.0.0/1 < - matches<br />
1.0.0.255/30 < - matches<br />
1.255.255.255/24 < - matches<br />
255.255.255.255/10 < - matches<br />
1.0.0.0/100 < - matches<br />
1.0.0.255/0 < - no match</pre><br />
<br />
=== Ethernet MAC address examples ===<br />
<br />
The following MAC address regex examples match lower or upper case hexadecimal values.<br />
<br />
MAC address format using hyphen between each octet (default output for PowerShell)<br />
<br />
<pre>^([0-9a-fA-F]{2}-){5}[0-9a-fA-F]{2}$<br />
<br />
98-E7-43-D1-74-D4 < - matches</pre><br />
<br />
MAC address format using colon (default for Linux)<br />
<br />
<pre>^([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}$<br />
<br />
98:E7:43:-D1:74:D4 < - matches</pre><br />
<br />
MAC address format without any delimiters<br />
<br />
<pre>^[0-9a-fA-F]{12}$<br />
<br />
98E743D174D4 < - matches</pre><br />
<br />
Combine all three above regex to match any of three<br />
<br />
<pre>(^([0-9a-fA-F]{2}-){5}[0-9a-fA-F]{2}$)|(^([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}$)|(^[0-9a-fA-F]{12}$)<br />
<br />
98-E7-43-D1-74-D4 < - matches<br />
98:E7:43:D1:74:D4 < - matches<br />
98E743D174D4 < - matches</pre><br />
<br />
''Note that you must assert start and end characters within the groups above.''<br />
<br />
If you use <code>^(([0-9a-fA-F]{2}-){5}[0-9a-fA-F]{2})|(([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2})|([0-9a-fA-F]{12})$</code> (assertions are outside groups) then invalid values would be matched:<br />
<br />
<pre>98-E7-43-D1-74-D4<br />
98-E7-43-D1-74-D40 < - invalid MAC, but matched regex<br />
<br />
98:E7:43:D1:74:D4<br />
98:E7:43:D1:74:D40 < - invalid MAC, but matched regex<br />
<br />
98E743D174D4<br />
98E743D174D40 < - invalid MAC, but matched regex</pre><br />
<br />
=== My regex notes for checking an ASN.1 GeneralizedTime type ===<br />
<br />
'''General (my wording!)'''<br />
* ^ means start of string<br />
* () means capture everything inside<br />
* | means or, aka "pipe" key<br />
* [] means single character with rules, rules are inside square brackets<br />
* \d means any digit<br />
* {} means quantity with specified conditions<br />
* ? means zero or one of previous character<br />
* $ means end of string<br />
<br />
Regex based on US requirements for time (within 200ms of event time) plus optional Z offset:<br />
<br />
<code>^20(19|20)([0][1-9]|[1][0-2])([0][1-9]|[1-2][\d]|[3][0-1])([0-1][\d]|[2][0-4])([0-5][\d])([0-5][\d]).\d{1,3}Z?$</code><br />
<br />
Regex explained<br />
* <code>^20(19|20)</code> = string starts with exactly 20 followed by 19 or 20 (match year "YYYY format")<br />
* <code>([0][1-9]|[1][0-2])</code> = next two characters must match either [0][1-9] or [1][0-2], which means 01-09 or 10-12 (match month "MM format")<br />
* <code>([0][1-9]|[1-2][\d]|[3][0-1])</code> = next two characters must match either [0][1-9] or [1-2][\d] or [3][0-1], which means 01-09 or 10-29 or 30-31(match day "DD format")<br />
* <code>([0-1][\d]|[2][0-4])</code> = next two characters must match either [0][\d] or [1][\d] or [2][0-4], which means 00-09 or 10-19 or 20-24 (match hour "HH format" in 24-hour format)<br />
* <code>([0-5][\d])</code> = next two characters must match [0-5][\d], which means 00-59 (match minutes "MM format")<br />
* <code>([0-5][\d])</code> = next two characters must match [0-5][\d], which means 00-59 (match minutes "SS format")<br />
* <code>.</code> = next character must be . (period)<br />
* <code>\d{1,3}</code> = next 1 to 3 characters must be any digit (match milliseconds .f, .ff, .fff format)<br />
* <code>Z?</code> = next character must be zero or one of Z (capital Z). Zero Z means Z is missing<br />
* <code>$</code> = end of string (no following characters)</pre><br />
<br />
Take examples, like 20190822005901.9Z, 20190801230059.09Z, 20190822005901.991Z, and play around in [https://regex101.com/ Regex101] online tool<br />
<br />
=== ISO 8601 Date and Time format ===<br />
<br />
Date and time with UTC<br />
<br />
<code>^2(\d\d\d)([0][1-9]|[1][0-2])([0][1-9]|[1-2][\d]|[3][0-1])T(([0-1][\d]|[2][0-3])([0-5][\d])([0-5][\d])|240000)Z?$</code><br />
<br />
This matches:<br />
* 20231106T240000Z<br />
<br />
== Miscellaneous Stuff ==<br />
<br />
=== Let's Encrypt ===<br />
Everyone should encrypt everything, end-to-end!<br />
<br />
[https://certbot.eff.org/docs/using.html#manual User Guide Manual]<br />
<br />
[https://certbot.eff.org/docs/using.html?highlight=renew#renewing-certificates User Guide renewing certificates]<br />
<br />
=== Ansible ===<br />
<br />
Red Hat [https://www.ansible.com/ Ansible] is a universal language, unraveling the mystery of how work gets done. Turn tough tasks into repeatable playbooks. Roll out enterprise-wide protocols with the push of a button. Give your team the tools to automate, solve, and share.<br />
<br />
=== Haxe ===<br />
<br />
[http://haxe.org/ Haxe] is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform's native capabilities.<br />
<br />
=== Action Script 3.0 ===<br />
<br />
[[Action Script]]<br />
<br />
==== Gosu ====<br />
<br />
[http://gosu-lang.org/ Gosu] is a programming language for the [http://www.java.com/en/download/faq/helpful_concepts.xml Java Virtual Machine (JVM)].<br />
<br />
== Storage Solutions ==<br />
<br />
[https://idndx.com/2017/07/15/building-a-home-nas-system-on-linux/ Building a home NAS system on Linux]<br />
<br />
== Gaming Technologies ==<br />
<br />
[http://www.udk.com/ UDK]<br />
<br />
[http://www.bigworldtech.com/ BigWorld Technology]<br />
<br />
== Graphic Input Devices ==<br />
<br />
Article about [https://www.creativebloq.com/features/best-drawing-tablet Best drawing tablet of 2018]<br />
<br />
== Interesting Hardware Articles ==<br />
<br />
[http://www.tomshardware.com/reviews/memory-module-upgrade,2264-8.html Benefits from larger amounts of RAM]<br />
<br />
[http://eecue.com/c/driveslag drive slag] data destruction method<br />
<br />
== Operating System stuff ==<br />
<br />
[[Linux]] area<br />
<br />
[[Solaris]] area<br />
<br />
[[Windows Operating System]]<br />
<br />
== Software stuff ==<br />
<br />
[[Software|My software notes]] section<br />
<br />
== Video Voice Fax companies ==<br />
<br />
[https://www.consilient-tech.com/ Consilient Technologies]<br />
<br />
[http://www.voiceage.com/ VoiceAge] is the forerunner in the development and dissemination of wideband speech and audio compression technologies in the wireless, internet and multimedia fields.<br />
<br />
== Digital Rights Management ==<br />
<br />
[https://pallycon.com/ PallyCon] provides cloud-based SaaS multi-DRM solution and Forensic Watermarking service.<br />
<br />
== general stuff ==<br />
<br />
[[Open Systems]]<br />
<br />
[[Dreamhost]] section<br />
<br />
[[web development]]<br />
<br />
[[Old Computer Stuff]]<br />
<br />
[[Multimedia Center Hardware]]<br />
<br />
[http://www.khronos.org/opencl/ OpenCL]<br />
<br />
[[Fun stuff]]<br />
<br />
[http://www.cablemap.info/ Greg's cable map]<br />
<br />
=== Females in technology resources ===<br />
<br />
[https://djangogirls.org/ Django Girls] is a non-profit organization and a community that empowers and helps women to organize free, one-day programming workshops by providing tools, resources and support.<br />
<br />
[https://kcwomenintech.org/ Kansas City Women in Technology] a grassroots organization helping to grow the number of women in technology careers in Kansas City.<br />
<br />
== Why I don't use Apple products ==<br />
<br />
[http://stallman.org/apple.html Richard Stallman] sums up the reasons I don't use Apple. No reason to duplicate.<br />
<br />
<center>[[Main Page|To Main Page]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Interesting_info&diff=3059Interesting info2023-10-30T14:08:23Z<p>Paul: /* Gardening */</p>
<hr />
<div>== Math Stuff ==<br />
<br />
[http://www.scottflansburg.com/ Scott Flansburg] the human calculator<br />
<br />
[https://www.thecountingbee.org/ The Counting Bee]<br />
<br />
[https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ A relatively easy-to-understand primer on elliptic curve cryptography]<br />
<br />
== Networking Stuff ==<br />
<br />
[https://www.garlandtechnology.com/tap-vs-span TAP vs SPAN article]<br />
<br />
The [https://fd.io/ Fast Data Project] (FD.io) is an open-source project aimed at providing the world's fastest and most secure networking data plane through Vector Packet Processing (VPP).<br />
<br />
[https://toonk.io/aws-network-performance-deep-dive/index.html AWS Network Performance Deep Dive] with DPDK mention.<br />
<br />
== Articles ==<br />
<br />
[http://www.howtogeek.com/135663/htg-explains-whats-the-difference-between-jailbreaking-rooting-and-unlocking/?utm_source=newsletter&utm_medium=email&utm_campaign=310113 How-To Geek] explains the difference between jailbreaking, rooting, and unlocking.<br />
<br />
[https://conferences.oreilly.com/software-architecture/sa-eu-2017/public/schedule/detail/61746 Resilient software design in a nutshell]<br />
<br />
[https://www.networkworld.com/article/3568608/are-newer-medical-iot-devices-less-secure-than-old-ones.html Are newer medical IoT devices less secure than old ones]<br />
<br />
[https://interestingengineering.com/biogenic-limestone-from-microalgae Biogenic limestone from microalgae]<br />
<br />
== Rat poison ==<br />
<br />
The most effective rat poison is based on Vitamin D:<br />
# rats eat a fatal dose on first feeding (they don't learn to avoid it)<br />
# pregnant rats eating the poison do not give birth to rats that are immune<br />
# If another animal eats the rat, there is little risk of secondary poisoning<br />
<br />
== Document tips ==<br />
<br />
[http://kimgusta.com/blog/15/How-to-Write-a-Datasheet/#.W4rPGehKiUk Design Your Product Datasheet for Skimming and Scanning]<br />
<br />
[https://pragmaticmarketing.com/blog/post/how-to-write-a-kick-butt-product-datasheet How to write a product datasheet]<br />
<br />
[https://bizfluent.com/info-7756520-difference-between-information-sheet-brochure.html Difference between information sheet and brochure]<br />
<br />
[https://www.psprint.com/resources/brochure-or-sales-sheet/ Brochure or Sales sheet]?<br />
<br />
[https://www.bmon.co.uk/2014/06/data-sheet/ What is a data sheet]?<br />
<br />
[http://edwardlowe.org/how-to-create-a-sales-brochure/ How to create a sales brochure]<br />
<br />
==== Testing tips ====<br />
<br />
[https://www.testingexcellence.com/test-strategy-and-test-plan/ Test Strategy and Test Plan]<br />
<br />
== Whiteboard software ==<br />
<br />
[https://www.softwarehow.com/best-whiteboard-animation-creator/ Best whiteboard animation tools]<br />
<br />
== e-Learning ==<br />
<br />
[https://community.articulate.com/ Community for E-Course Creators]<br />
<br />
[http://blogs.articulate.com/rapid-elearning/create-hand-drawn-graphics/ How to Create Your Own Hand-Drawn Graphics]<br />
<br />
[https://blogs.articulate.com/rapid-elearning/essential-guide-visual-thinking-e-learning/ Essential Guide to Visual Thinking for E-Learning]<br />
<br />
[http://theelearningcoach.com/elearning_design/a-framework-for-developing-online-courses/ A Framework for Developing Online Learning]<br />
<br />
The [https://hr.un.org/sites/hr.un.org/files/OLF_2018_v14_0.pdf Online Learning Framework] is a set of tools and recommendations that provides guidance and promotes shared standards for the development of online learning products at the United Nations.<br />
<br />
The [https://onlinelearningconsortium.org/ Online Learning Consortium™ (OLC)] is a collaborative community of higher education leaders and innovators, dedicated to advancing quality digital teaching and learning experiences designed to reach and engage the modern learner – anyone, anywhere, anytime.<br />
<br />
The [https://www.goodfirms.co/blog/best-free-open-source-LMS-Software-solutions Best 8 Free and Open Source Learning Management System (LMS) Software]<br />
<br />
[https://moodle.org/ Moodle] is the world's most popular learning management system.<br />
<br />
=== Moodle stuff ===<br />
<br />
[https://edwiser.org/lms-services/ Edwiser Moodle consultants]<br />
<br />
A [https://moodle.org/plugins/mod_game game activity module] makes use of questions, quizzes and glossaries to create offer a variety of interactive games.<br />
<br />
Author of above module [https://scholar.google.gr/citations?user=jFFbeLsAAAAJ&hl=el Vasilis Daloukas]<br />
<br />
== Nginx ==<br />
<br />
[https://openconnect.netflix.com/en/software/ Netflix open connect] mentioning Nginx<br />
<br />
== Product Management ==<br />
<br />
[https://medium.com/@joshua_e_k/python-for-product-managers-efeb71848aa9 Python for Product Managers]<br />
<br />
== Creating Technical Documentation ==<br />
<br />
Blog: [https://plan.io/blog/technical-documentation/ 5 Steps to Create Technical Documentation That’s (Actually) Helpful]<br />
<br />
== Lawful surveillance vendors ==<br />
<br />
[[Lawful surveillance vendors]]<br />
<br />
== Analysis info ==<br />
<br />
[https://shadowdragon.io/understanding-link-analysis-and-using-it-in-investigations/ Understanding link analysis and using it in investigations]<br />
<br />
[https://www.palantir.com/solutions/law-enforcement/ Palantir Law Enforcement]<br />
<br />
[https://ciphertrace.com/ Cipher Trace]<br />
<br />
[https://www.cellebrite.com/en/home/ Cellebrite]<br />
<br />
== Speech processing ==<br />
<br />
[https://www.vocapia.com/ Vocapia Research] develops leading-edge, multilingual speech processing technologies. These technologies enable large vocabulary continuous speech recognition, automatic audio segmentation, language identification, speaker diarization and audio-text synchronization.<br />
<br />
== Text processing ==<br />
<br />
[https://fasttext.cc/docs/en/language-identification.html FastText] is an open-source, free, lightweight library that allows users to learn text representations and text classifiers. It works on standard, generic hardware. Models can later be reduced in size to even fit on mobile devices.<br />
<br />
[https://amitness.com/2019/07/identify-text-language-python/ Identify text language using Python]<br />
<br />
== Video processing ==<br />
<br />
[https://motion-project.github.io/index.html Motion] is a program that monitors the video signal from one or more cameras and is able to detect if a significant part of the picture has changed. Or in other words, it can detect motion.<br />
<br />
== Short Messaging Service (SMS) ==<br />
<br />
[https://www.contextis.com/us/blog/binary-sms-the-old-backdoor-to-your-new-thing Binary SMS - The old backdoor to your new thing]<br />
<br />
== Space Stuff ==<br />
<br />
[https://www.washingtonpost.com/opinions/2022/07/12/james-webb-space-telescope-photos-explanation/ Why James Webb Space Telescope is so cool]<br />
<br />
[https://unchartedterritories.tomaspueyo.com/p/how-starship-will-change-humanity How SpaceX starship will change humanity]<br />
<br />
== Retirement ==<br />
<br />
[https://www.netcredit.com/blog/cost-of-retirement/ Cost of retirement]<br />
<br />
== Income levels ==<br />
<br />
[https://smartasset.com/data-studies/how-to-be-middle-class-americas-largest-cities-2023 Middle class Americans by City in 2023]<br />
<br />
== Gardening ==<br />
<br />
[https://www.houseandgarden.co.uk/gallery/designing-a-garden Designing a garden]<br />
<br />
== Traffic ==<br />
<br />
[https://theconversation.com/what-are-roundabouts-a-transportation-engineer-explains-the-safety-benefits-of-these-circular-intersections-215412 Transportation engineer explains the safety benefits of roundabouts]<br />
<br />
<center>[[Main Page| To Main Page]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Software&diff=3058Software2023-10-11T19:17:26Z<p>Paul: /* Other software */</p>
<hr />
<div>== Nginx ==<br />
<br />
See [https://en.wikipedia.org/wiki/Nginx Nginx] on Wikipedia.<br />
<br />
[[My Nginx notes]] is a web server which can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.<br />
<br />
== Node.js ==<br />
<br />
See [https://en.wikipedia.org/wiki/Node.js Node.js] on Wikipedia.<br />
<br />
[[My Node.js notes]]<br />
<br />
== Apache ==<br />
<br />
[[Apache | My Apache notes]]<br />
<br />
== Ubuntu ==<br />
<br />
[[Ubuntu | My Ubuntu notes]]<br />
<br />
== Other software ==<br />
<br />
[[Open Source Software]]<br />
<br />
[http://www.profantasy.com/ Profantasy] Software brings you everything you need to create great maps for your games. There are symbols and tools for overland maps from all ages, buildings, floorplans, heraldry and many other uses. We help you create more and better maps, more quickly, than any comparable software.<br />
<br />
[[Microsoft]]<br />
<br />
[[Filezilla]] section<br />
<br />
[[PHP]] section<br />
<br />
[[Vi]] section<br />
<br />
[[My GIMP notes]]<br />
<br />
[[BASH shell]] section<br />
<br />
[[VSFTP]] Section<br />
<br />
[[Graphic Software]]<br />
<br />
[[Software version control]]<br />
<br />
[http://www.techsmith.com/ Tech'''Smith''' Software] makers of SnagIt, Camtasia Studio, Jing, and more.<br />
<br />
My notes on [[White Board Applications]]<br />
<br />
[https://dbschema.com/editions.html DbSchema] for db planning<br />
<br />
[[wiki notes]]<br />
<br />
<br />
<center>[[Computing | To Computing]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Ubuntu&diff=3057Ubuntu2023-09-05T13:45:58Z<p>Paul: /* Add a User */</p>
<hr />
<div>== Shell commands ==<br />
<br />
Enable root account (not recommended):<br />
<pre>$sudo passwd root</pre><br />
<br />
Disable root account you lock root account:<br />
<pre>$sudo passwd -l root</pre><br />
<br />
Want to use root @ console:<br />
<pre>$sudo -i</pre><br />
<br />
[https://help.ubuntu.com/community/WindowsDualBoot Windows Dual Boot] page<br />
<br />
[https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows Recovering Ubuntu After Windows Install]<br />
<br />
[https://wiki.ubuntu.com/Grub2 Grub2] on Ubuntu wiki<br />
<br />
[http://www.howtogeek.com/howto/43471/how-to-configure-the-linux-grub2-boot-menu-the-easy-way/ Grub2 GUI] Customizer<br />
<br />
For support-related question you can use [https://answers.launchpad.net/ Launchpad]. You can also search the complete history of questions and answers.<br />
<br />
[http://ubuntuforums.org/ Ubuntu web forums]<br />
<br />
[http://ubuntuforums.org/showthread.php?t=1195275 Grub 2] basics<br />
<br />
=== Enable SSH server ===<br />
<br />
<code>apt-get install openssh-server</code><br />
<br />
[https://coderwall.com/p/yz-2_a/limit-ssh-access-by-ip-address Secure SSH server using /etc/hosts.allow]<br />
<br />
=== Add a User ===<br />
<br />
Example adding a user with username johndoe. Follow the instructions provided by the command.<br />
<br />
<code>sudo adduser johndoe</code><br />
<br />
==== sudo group stuff ====<br />
<br />
Add user to sudo group<br />
<br />
<code>sudo usermod -aG sudo <USER_NAME></code><br />
<br />
Verify user belongs to sudo group<br />
<br />
<code>groups <USER_NAME></code><br />
<br />
Verify sudo access<br />
<br />
<code>su - <USER_NAME></code><br />
<br />
Remove user from sudo group<br />
<br />
<code>sudo deluser <USER_NAME> sudo</code><br />
<br />
=== Networking utilities ===<br />
<br />
See IP address information<br />
<br />
<code>ip a</code><br />
<br />
==== Configure hostname ====<br />
<br />
[https://linuxize.com/post/how-to-change-hostname-on-ubuntu-18-04/ How to change hostname on Ubuntu 18 04]<br />
<br />
==== systemctl ====<br />
<br />
Verify which processes run on Ubuntu 18.04 start up use <code>$ sudo systemctl list-unit-files</code>.<br />
<br />
=== Check version of Ubuntu ===<br />
<code>$ cat /etc/os-release</code><br />
<br />
== CLI Software Management ==<br />
<br />
Synchronize package index from Internet. Location of repositories <code>/etc/apt/sources.list</code><br />
<pre>sudo apt-get update</pre><br />
Install newest versions of all software packages<br />
<pre>sudo apt-get upgrade</pre><br />
Update distribution<br />
<pre>sudo apt-get dist-upgrade</pre><br />
Install package (if already installed, will attempt to update package)<br />
<pre>apt-get install package-name</pre><br />
List installed packages<br />
<pre>apt list --installed</pre><br />
<br />
List installed packages that start with 'python'<br />
<pre>$ apt list -a --installed python*</pre><br />
<br />
== Python on Ubuntu Notes ==<br />
<br />
See [[ Python | My Python Notes]] for information not specific to Ubuntu and Python.<br />
<br />
Verify Python 3 is installed<br />
<pre>anon@hammerhead:~$ python --version<br />
<br />
Command 'python' not found, but can be installed with:<br />
<br />
sudo apt install python3 <br />
sudo apt install python <br />
sudo apt install python-minimal<br />
<br />
You also have python3 installed, you can run 'python3' instead.<br />
<br />
anon@hammerhead:~$ python3 --version <----- Python 3 installed.<br />
Python 3.6.7 <----- Version 3.6.7</pre><br />
<br />
Verify Python 3 PIP installed<br />
<pre>$ pip3 --version<br />
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)</pre><br />
<br />
To install Python 3 PIP<br />
<pre>$ sudo apt-get install -y python3-pip</pre><br />
<br />
I use Python virtual environments. Verify Python venv module is installed<br />
<pre>$ apt list -a --installed *venv* <----- If nothing with Python 3 venv comes back then you most install venv module</pre><br />
<br />
To install Python 3 venv module<br />
<pre>$ sudo apt-get install -y python3-venv</pre><br />
<br />
Create virtual environment. I keep my Python virtual environments in a single directory. To create directory <code>$ mkdir python-venv</code><br />
<br />
Switch do directory <code>$ cd python-venv/</code><br />
<br />
Create virtual environment<br />
<pre>$ python3 -m venv udmey-django</pre><br />
<br />
Activate virtual environment<br />
<pre>$ source udmey-django/bin/activate</pre><br />
<br />
Prompt changes to reflect virtual environment<br />
<pre>(udmey-django) anon@hammerhead:~/python-venv$</pre><br />
<br />
Note: Within virtual environment, you can use the command python instead of python3, and pip instead of pip3.<br />
<br />
Deactivate virtual environment and prompt returns to normal<br />
<pre>$ deactivate</pre><br />
<br />
== mongoDB ==<br />
<br />
[[My MongoDB notes]]<br />
<br />
== PostgreSQL ==<br />
<br />
=== Install PostgreSQL ===<br />
<br />
<pre>$ sudo apt install postgresql postgresql-contrib<br />
...<br />
Success. You can now start the database server using:<br />
<br />
/usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start<br />
<br />
Ver Cluster Port Status Owner Data directory Log file<br />
10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log<br />
update-alternatives: using /usr/share/postgresql/10/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode<br />
Setting up postgresql (10+190) ...<br />
Setting up postgresql-contrib (10+190) ...<br />
Processing triggers for systemd (237-3ubuntu10.11) ...<br />
Processing triggers for ureadahead (0.100.0-20) ...</pre><br />
<br />
=== Use PostgreSQL ===<br />
<br />
Switch to postgres account<br />
<pre>sudo -i postgres</pre><br />
Access PostgreSQL prompt<br />
<pre>psql</pre><br />
Exit PostgreSQL prompt<br />
<pre>\q</pre><br />
Log directly into PostgreSQL prompt with postgres user<br />
<pre>sudo -u postgres psql</pre><br />
Add user (username must be same as PostgreSQL role and database)<br />
<pre>sudo adduser user_name</pre><br />
Check current connection information<br />
<pre>\conninfo</pre><br />
<br />
<b>While logged in as postgres user...</b><br />
<br />
Create a new role. Use <code>man createuser</code> for more information.<br />
<pre>createuser --interactive</pre><br />
Create new database<br />
<pre>createdb db_name</pre><br />
Same user connect to different database<br />
<pre>psql -d postgres</pre><br />
<br />
== Nginx ==<br />
<br />
[[My Nginx notes]]<br />
<br />
[https://www.tecmint.com/install-nginx-with-virtual-hosts-and-ssl-certificate/ Install Nginx with virtual hosts and SSL certificates]<br />
<br />
== Apache 2 ==<br />
<br />
=== Resources ===<br />
<br />
[https://help.ubuntu.com/lts/serverguide/httpd.html Ubuntu server guide to HTTPD]<br />
<br />
[https://help.ubuntu.com/community/OpenSSL#SSL_Certificates Ubuntu Open SSL guide]<br />
<br />
[https://help.ubuntu.com/lts/serverguide/certificates-and-security.html.en Ubuntu Certificates and Security]<br />
<br />
[http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html SSL Certificate HOWTO] not Ubuntu specific<br />
<br />
[https://stuff-things.net/2015/09/28/configuring-apache-for-ssl-client-certificate-authentication/ Configure Apache for SSL client certificate authentication]<br />
<br />
=== Installation ===<br />
<br />
Update all your software and install Apache 2<br />
<br />
<pre># apt-get update<br />
# apt-get upgrade<br />
# apt install apache2</pre><br />
<br />
Verify Apache is running<br />
<pre># systemctl status apache2<br />
● apache2.service - The Apache HTTP Server<br />
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)<br />
Drop-In: /lib/systemd/system/apache2.service.d<br />
└─apache2-systemd.conf<br />
Active: active (running) since Sun 2018-10-21 14:44:30 CDT; 11min ago<br />
Main PID: 17131 (apache2)<br />
Tasks: 55 (limit: 4181)<br />
CGroup: /system.slice/apache2.service<br />
├─17131 /usr/sbin/apache2 -k start<br />
├─17132 /usr/sbin/apache2 -k start<br />
└─17134 /usr/sbin/apache2 -k start<br />
<br />
Oct 21 14:44:30 apu02 systemd[1]: Starting The Apache HTTP Server...<br />
Oct 21 14:44:30 apu02 apachectl[17120]: AH00558: apache2: Could not reliably determine the server's<br />
Oct 21 14:44:30 apu02 systemd[1]: Started The Apache HTTP Server.</pre><br />
<br />
=== Firewall ===<br />
<br />
Update firewall to allow only port 443 (default HTTPS TCP port)<br />
<br />
<pre># ufw app list<br />
Available applications:<br />
Apache<br />
Apache Full<br />
Apache Secure<br />
OpenSSH<br />
<br />
# ufw allow 'Apache Secure'<br />
<br />
# ufw status verbose | grep 443<br />
443/tcp (Apache Secure) ALLOW IN Anywhere<br />
443/tcp (Apache Secure (v6)) ALLOW IN Anywhere (v6)</pre><br />
<br />
== Teamspeak 3 setup on Ubuntu 16.04 and 18.x via command line ==<br />
Followed steps at [https://www.vultr.com/docs/how-to-install-teamspeak-3-server-on-ubuntu-16-04-64-bit How to install Teamspeak 3 server on Ubuntu 16.04 64-bit] to install Teamspeak 3 and get basic server running.<br />
<br />
If you want to customize the server port follow next steps.<br />
<br />
Install simple command-line program named [https://www.sqlite.org/cli.html sqlite3]. [https://www.sitepoint.com/getting-started-sqlite3-basic-commands/ How to use sqlite]<br />
<br />
<pre>robot00@apu00:~$ sudo apt install sqlite3</pre><br />
<br />
Launch sqlite3 using Teamspeak 3 sqlite database file:<br />
<br />
<pre>robot00@apu00:~$ sudo sqlite3 /home/teamspeak/ts3server.sqlitedb<br />
SQLite version 3.11.0 2016-02-15 17:29:24<br />
Enter ".help" for usage hints.</pre><br />
<br />
Update port command:<br />
<br />
<pre>sqlite> update servers set server_port=<CUSTOM UDP Port>;</pre><br />
<br />
Restart Teamspeak 3 server<br />
<br />
<pre>robot00@apu00:~$ systemctl restart teamspeak.service</pre><br />
<br />
Test your connection using the <CUSTOM UDP Port><br />
<br />
=== Upgrade Teamspeak3 server ===<br />
<br />
[https://www.gazblog.com/2019/01/update-teamspeak-3-server-on-ubuntu-18-04/ original steps]<br />
<br />
Login to SSH as root<br />
<br />
Stop your current Teamspeak 3 Server <code>systemctl stop teamspeak.service</code><br />
<br />
Change to your teamspeak user <code>cd /home/teamspeak/;su teamspeak</code><br />
<br />
Download Teamspeak, extract it, update and tidy up.<br />
<pre>wget https://files.teamspeak-services.com/releases/server/3.9.1/teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
tar xvfj teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
cd teamspeak3-server_linux_amd64<br />
cp * -R /home/teamspeak<br />
cd ..<br />
rm -r teamspeak3-server_linux_amd64<br />
rm teamspeak3-server_linux_amd64-3.9.1.tar.bz2</pre><br />
<br />
Return to root and start the Teamspeak server<br />
<pre>exit<br />
systemctl start teamspeak.service<br />
</pre><br />
<br />
Check to make you can connect to Teamspeak 3 server<br />
<br />
== Factorio Headless Setup ==<br />
<br />
[[My Factorio Info]]<br />
<br />
== Hardware ==<br />
<br />
Identify video card:<br />
<pre>paul@congo:~$ lspci -nn | grep VGA<br />
01:00.0 VGA compatible controller [0300]: nVidia Corporation G92 [GeForce 8800 GT] [10de:0611] (rev a2)</pre><br />
<br />
Verify interface speed<br />
<br />
<code>cat /sys/class/net/<interface>/speed</code><br />
<br />
replace <interface> with name of your NIC (e.g. eth0)<br />
<br />
[[Ubuntu video card]]<br />
<br />
<center>[[Linux|To Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Factorio_Info&diff=3056My Factorio Info2023-09-04T20:49:00Z<p>Paul: /* Factorio Headless Setup */</p>
<hr />
<div>== Factorio Headless Setup ==<br />
<br />
Resources:<br />
* [https://wiki.factorio.com/Multiplayer Multiplayer Factorio wiki]<br />
* Stable [https://factorio.com/get-download/stable/headless/linux64 Factorio headless] server<br />
<br />
Check that your version of glibc is >= 2.18.<br />
<br />
<pre>robot01@apu01:~$ ldd --version<br />
ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23<br />
Copyright (C) 2016 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
Written by Roland McGrath and Ulrich Drepper.</pre><br />
<br />
Output of ldd command confirms glibc version >2.18.<br />
<br />
Switch to <code>$ cd /opt</code> directory and download latest Factorio stable headless version (1.1.87 as of this writing)<br />
<br />
<pre>$ sudo wget https://factorio.com/get-download/stable/headless/linux64<br />
--2023-09-04 14:28:09-- https://factorio.com/get-download/stable/headless/linux64<br />
Resolving factorio.com (factorio.com)... 2606:4700:20::681a:f58, 2606:4700:20::ac43:47c5, 2606:4700:20::681a:e58, ...<br />
Connecting to factorio.com (factorio.com)|2606:4700:20::681a:f58|:443... connected.<br />
HTTP request sent, awaiting response... 302 Found<br />
Location: https://dl.factorio.com/releases/factorio_headless_x64_1.1.87.tar.xz?secure=4g154TPABPYOpo7oo2Cnvw,1693859289 [following]<br />
--2023-09-04 14:28:09-- https://dl.factorio.com/releases/factorio_headless_x64_1.1.87.tar.xz?secure=4g154TPABPYOpo7oo2Cnvw,1693859289<br />
Resolving dl.factorio.com (dl.factorio.com)... 2a02:6ea0:d800::2, 212.102.46.8<br />
Connecting to dl.factorio.com (dl.factorio.com)|2a02:6ea0:d800::2|:443... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: 58853524 (56M) [application/octet-stream]<br />
Saving to: ‘linux64’<br />
<br />
linux64 100%[==========================================================>] 56.13M 32.9MB/s in 1.7s <br />
<br />
2023-09-04 14:28:11 (32.9 MB/s) - ‘linux64’ saved [58853524/58853524]</pre><br />
<br />
Rename file to match version (1.1.87 in this example)<br />
<pre>$ sudo mv linux64 factorio_headless_x64_1.1.87.tar.xz</pre><br />
<br />
Extract archived and zipped file<br />
<pre>$ sudo tar -xJf factorio_headless_x64_1.1.87.tar.xz<br />
$ ls -l<br />
total 57480<br />
drwxr-xr-x 8 steamy steamy 4096 Sep 4 14:32 factorio<br />
-rw-r--r-- 1 root root 58853524 Jul 4 05:36 factorio_headless_x64_1.1.87.tar.xz</pre><br />
<br />
Remove file (save space, you can always download the file again, if needed)<br />
<pre>robot01@apu01:/opt$ sudo rm factorio_headless_x64_1.1.87.tar.xz</pre><br />
<br />
Add a new user to run factorio and assign ownership of <code>/opt/factorio</code> directory to same user<br />
<pre>$ sudo useradd factorio<br />
$ sudo chown -R factorio:factorio /opt/factorio/</pre><br />
<br />
<br />
Verify permissions show factorio for both user and group<br />
<pre>$ ls -l /opt/factorio</pre><br />
<br />
<br />
Test Factorio binary by switching to factorio user then start server<br />
<pre>robot01@apu01:/opt$ sudo su - factorio<br />
No directory, logging in with HOME=/<br />
$</pre><br />
<br />
As factorio user create <code>/opt/factorio/</code> saves directory. I used saves directory.<br />
<pre>$ mkdir /opt/factorio/saves</pre><br />
<br />
Start server and look for something like "File /savename does not exist."<br />
<pre>$ /opt/factorio/bin/x64/factorio --start-server savename<br />
0.000 2018-05-01 21:20:47; Factorio 0.16.36 (build 36253, linux64, headless)<br />
0.260 Operating system: Linux (Ubuntu 16.04)<br />
0.260 Program arguments: "/opt/factorio/bin/x64/factorio" "--start-server" "savename"<br />
0.260 Read data path: /opt/factorio/data<br />
0.260 Write data path: /opt/factorio [103696/111098MB]<br />
0.260 Binaries path: /opt/factorio/bin<br />
0.304 System info: [CPU: AMD G-T40E Processor, 2 cores, RAM: 3550 MB]<br />
0.304 Environment: DISPLAY=<unset>, WAYLAND_DISPLAY=<unset><br />
0.305 Running in headless mode<br />
0.316 Error GlobalModSettings.cpp:107: Failed to migrate mod settings file: Error when opening /opt/factorio/mods/mod-settings.json for reading: No such file or directory<br />
0.322 Loading mod core 0.0.0 (data.lua)<br />
0.388 Loading mod base 0.16.36 (data.lua)<br />
1.063 Loading mod base 0.16.36 (data-updates.lua)<br />
1.313 Checksum for core: 1316978547<br />
1.313 Checksum of base: 4140083139<br />
2.006 Info PlayerData.cpp:67: Local player-data.json unavailable<br />
2.006 Info PlayerData.cpp:72: Cloud player-data.json unavailable<br />
2.012 Custom inputs active: 0<br />
2.015 Factorio initialised<br />
2.016 Info ServerSynchronizer.cpp:29: nextHeartbeatSequenceNumber(0) initialized Synchronizer nextTickClosureTick(0).<br />
2.016 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(Ready) to(PreparedToHostGame)<br />
2.016 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(PreparedToHostGame) to(CreatingGame)<br />
2.017 Loading map /savename<br />
2.017 Error ServerMultiplayerManager.cpp:96: MultiplayerManager failed: "File /savename does not exist."<br />
2.017 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(CreatingGame) to(InitializationFailed)<br />
2.017 Info GlobalContext.cpp:694: Waiting for child processes to exit:<br />
2.020 Info ServerMultiplayerManager.cpp:142: Quitting multiplayer connection.<br />
2.020 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(InitializationFailed) to(Closed)<br />
2.062 Info UDPSocket.cpp:206: Closing socket<br />
2.065 Goodbye</pre><br />
<br />
At this point you can load up saved games or create some games. Before that, I want to install Factorio init script<br />
<br />
Exit from factorio user back to sudo account<br />
<pre>$ exit<br />
logout</pre><br />
<br />
Switch to <code>/opt</code> directory<br />
<pre>$ cd /opt</pre><br />
<br />
I had to install git on my Ubuntu system<br />
<pre>$ sudo apt install git</pre><br />
<br />
Clone Factorio init script from github<br />
<pre>$ sudo git clone https://github.com/Bisa/factorio-init.git<br />
Cloning into 'factorio-init'...<br />
remote: Enumerating objects: 1028, done.<br />
remote: Counting objects: 100% (145/145), done.<br />
remote: Compressing objects: 100% (71/71), done.<br />
remote: Total 1028 (delta 70), reused 121 (delta 60), pack-reused 883<br />
Receiving objects: 100% (1028/1028), 265.92 KiB | 2.95 MiB/s, done.<br />
Resolving deltas: 100% (584/584), done.<br />
anon@steamnuc00:/opt$ git --version<br />
git version 2.25.1</pre><br />
<br />
Validate factorio-init directory exists<br />
<pre>$ ls -l /opt<br />
drwxr-xr-x 8 steamy steamy 4096 Sep 4 14:53 factorio<br />
drwxr-xr-x 5 root root 4096 Sep 4 15:00 factorio-init</pre><br />
<br />
Change ownership to Factorio user<br />
<br />
<pre>$ sudo chown -R steamy:steamy /opt/factorio-init/</pre><br />
<br />
Edit config.example and add your Factorio users.<br />
<br />
<pre>$ sudo vi /opt/factorio-init/config.example</pre><br />
<br />
Here are my edits to config.example after making edits<br />
<pre>$ grep -i steamy factorio-init/config.example <br />
USERNAME=steamy<br />
USERGROUP=steamy</pre><br />
<br />
Edit factorio.service.example with your default values<br />
<br />
<pre>$ sudo vi /opt/factorio-init/extras/factorio.service.example</pre><br />
<br />
Here are my edits to factorio.service.example after making edits<br />
<br />
<pre>$ grep -i steamy /opt/factorio-init/extras/factorio.service.example<br />
User=steamy<br />
Group=steamy</pre><br />
<br />
Make Factorio start on operating system boot and restart if failure (configurable - I kept defaults for now)<br />
<pre>$ sudo cp /opt/factorio-init/extras/factorio.service.example /etc/systemd/system/factorio.service<br />
$ sudo systemctl daemon-reload</pre><br />
<br />
Sysvinit<br />
<pre>$ sudo ln -s /opt/factorio-init/factorio /etc/init.d/factorio<br />
$ sudo chmod +x /opt/factorio-init/factorio</pre><br />
<br />
Show help<br />
<pre>$ service factorio help<br />
Usage: /etc/init.d/factorio COMMAND<br />
<br />
Available commands:<br />
start Starts the server<br />
stop Stops the server<br />
restart Restarts the server<br />
status Displays server status<br />
players-online Shows online players<br />
players Shows all players<br />
cmd [command/message] Open interactive commandline or send a single command to the server<br />
log [--tail|-t] Print the full server log, optionally tail the log to follow in real time<br />
chatlog [--tail|-t] Print the current chatlog, optionally tail the log to follow in real time<br />
new-game name [map-gen-settings] [map-settings] Stops the server and creates a new game with the specified<br />
name using the specified map gen settings and map settings json files<br />
save-game name Stops the server and saves game to specified save<br />
load-save name Stops the server and loads the specified save<br />
install [tarball] Installs the server with optional specified tarball<br />
(omit to download and use the latest headless server from Wube)<br />
update [--dry-run] Updates the server<br />
invocation Outputs the invocation for debugging purpose<br />
listcommands List all init-commands<br />
listsaves List all saves<br />
version Prints the binary version<br />
mod Manage mods (see /etc/init.d/factorio mod help for more information)<br />
help Shows this help message</pre><br />
<br />
Setup Autocompletion<br />
<pre>$ sudo ln -s /opt/factorio-init/extras/bash_autocomplete /etc/bash_completion.d/factorio<br />
$ sudo ln -s /opt/factorio-init/factorio /usr/local/bin/factorio</pre><br />
<br />
Copy example server settings (make any changes you want to copy)<br />
<pre>$ sudo cp /opt/factorio/data/server-settings.example.json /opt/factorio/data/server-settings.json</pre><br />
<br />
Copy example configuration (make any changes you want to copy)<br />
<pre>$ sudo cp /opt/factorio-init/config.example /opt/factorio-init/config</pre><br />
<br />
Make any changes to config ini<br />
<pre>robot01@apu01:/opt/factorio$ sudo vi /opt/factorio/config/config.ini</pre><br />
<br />
=== Update headless server ===<br />
<br />
download latest headless version<br />
<br />
unzip and untar<br />
<br />
<pre>sudo tar -xJf linux64</pre><br />
<br />
change permissions to your dedicated factorio user<br />
<br />
<pre>sudo chown -R steamy:steamy factorio</pre><br />
<br />
launch game<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Factorio_Info&diff=3055My Factorio Info2023-09-04T20:34:35Z<p>Paul: /* Factorio Headless Setup */</p>
<hr />
<div>== Factorio Headless Setup ==<br />
<br />
Resources:<br />
* [https://wiki.factorio.com/Multiplayer Multiplayer Factorio wiki]<br />
* Stable [https://factorio.com/get-download/stable/headless/linux64 Factorio headless] server<br />
<br />
Check that your version of glibc is >= 2.18.<br />
<br />
<pre>robot01@apu01:~$ ldd --version<br />
ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23<br />
Copyright (C) 2016 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
Written by Roland McGrath and Ulrich Drepper.</pre><br />
<br />
Output of ldd command confirms glibc version >2.18.<br />
<br />
Switch to <code>$ cd /opt</code> directory and download latest Factorio stable headless version (1.1.87 as of this writing)<br />
<br />
<pre>$ sudo wget https://factorio.com/get-download/stable/headless/linux64<br />
--2023-09-04 14:28:09-- https://factorio.com/get-download/stable/headless/linux64<br />
Resolving factorio.com (factorio.com)... 2606:4700:20::681a:f58, 2606:4700:20::ac43:47c5, 2606:4700:20::681a:e58, ...<br />
Connecting to factorio.com (factorio.com)|2606:4700:20::681a:f58|:443... connected.<br />
HTTP request sent, awaiting response... 302 Found<br />
Location: https://dl.factorio.com/releases/factorio_headless_x64_1.1.87.tar.xz?secure=4g154TPABPYOpo7oo2Cnvw,1693859289 [following]<br />
--2023-09-04 14:28:09-- https://dl.factorio.com/releases/factorio_headless_x64_1.1.87.tar.xz?secure=4g154TPABPYOpo7oo2Cnvw,1693859289<br />
Resolving dl.factorio.com (dl.factorio.com)... 2a02:6ea0:d800::2, 212.102.46.8<br />
Connecting to dl.factorio.com (dl.factorio.com)|2a02:6ea0:d800::2|:443... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: 58853524 (56M) [application/octet-stream]<br />
Saving to: ‘linux64’<br />
<br />
linux64 100%[==========================================================>] 56.13M 32.9MB/s in 1.7s <br />
<br />
2023-09-04 14:28:11 (32.9 MB/s) - ‘linux64’ saved [58853524/58853524]</pre><br />
<br />
Rename file to match version (1.1.87 in this example)<br />
<pre>$ sudo mv linux64 factorio_headless_x64_1.1.87.tar.xz</pre><br />
<br />
Extract archived and zipped file<br />
<pre>$ sudo tar -xJf factorio_headless_x64_1.1.87.tar.xz<br />
$ ls -l<br />
total 57480<br />
drwxr-xr-x 8 steamy steamy 4096 Sep 4 14:32 factorio<br />
-rw-r--r-- 1 root root 58853524 Jul 4 05:36 factorio_headless_x64_1.1.87.tar.xz</pre><br />
<br />
Remove file (save space, you can always download the file again, if needed)<br />
<pre>robot01@apu01:/opt$ sudo rm factorio_headless_x64_1.1.87.tar.xz</pre><br />
<br />
Add a new user to run factorio and assign ownership of <code>/opt/factorio</code> directory to same user<br />
<pre>$ sudo useradd factorio<br />
$ sudo chown -R factorio:factorio /opt/factorio/</pre><br />
<br />
<br />
Verify permissions show factorio for both user and group<br />
<pre>$ ls -l /opt/factorio</pre><br />
<br />
<br />
Test Factorio binary by switching to factorio user then start server<br />
<pre>robot01@apu01:/opt$ sudo su - factorio<br />
No directory, logging in with HOME=/<br />
$</pre><br />
<br />
As factorio user create <code>/opt/factorio/</code> saves directory. I used saves directory.<br />
<pre>$ mkdir /opt/factorio/saves</pre><br />
<br />
Start server and look for something like "File /savename does not exist."<br />
<pre>$ /opt/factorio/bin/x64/factorio --start-server savename<br />
0.000 2018-05-01 21:20:47; Factorio 0.16.36 (build 36253, linux64, headless)<br />
0.260 Operating system: Linux (Ubuntu 16.04)<br />
0.260 Program arguments: "/opt/factorio/bin/x64/factorio" "--start-server" "savename"<br />
0.260 Read data path: /opt/factorio/data<br />
0.260 Write data path: /opt/factorio [103696/111098MB]<br />
0.260 Binaries path: /opt/factorio/bin<br />
0.304 System info: [CPU: AMD G-T40E Processor, 2 cores, RAM: 3550 MB]<br />
0.304 Environment: DISPLAY=<unset>, WAYLAND_DISPLAY=<unset><br />
0.305 Running in headless mode<br />
0.316 Error GlobalModSettings.cpp:107: Failed to migrate mod settings file: Error when opening /opt/factorio/mods/mod-settings.json for reading: No such file or directory<br />
0.322 Loading mod core 0.0.0 (data.lua)<br />
0.388 Loading mod base 0.16.36 (data.lua)<br />
1.063 Loading mod base 0.16.36 (data-updates.lua)<br />
1.313 Checksum for core: 1316978547<br />
1.313 Checksum of base: 4140083139<br />
2.006 Info PlayerData.cpp:67: Local player-data.json unavailable<br />
2.006 Info PlayerData.cpp:72: Cloud player-data.json unavailable<br />
2.012 Custom inputs active: 0<br />
2.015 Factorio initialised<br />
2.016 Info ServerSynchronizer.cpp:29: nextHeartbeatSequenceNumber(0) initialized Synchronizer nextTickClosureTick(0).<br />
2.016 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(Ready) to(PreparedToHostGame)<br />
2.016 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(PreparedToHostGame) to(CreatingGame)<br />
2.017 Loading map /savename<br />
2.017 Error ServerMultiplayerManager.cpp:96: MultiplayerManager failed: "File /savename does not exist."<br />
2.017 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(CreatingGame) to(InitializationFailed)<br />
2.017 Info GlobalContext.cpp:694: Waiting for child processes to exit:<br />
2.020 Info ServerMultiplayerManager.cpp:142: Quitting multiplayer connection.<br />
2.020 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(InitializationFailed) to(Closed)<br />
2.062 Info UDPSocket.cpp:206: Closing socket<br />
2.065 Goodbye</pre><br />
<br />
At this point you can load up saved games or create some games. Before that, I want to install Factorio init script<br />
<br />
Exit from factorio user back to sudo account<br />
<pre>$ exit<br />
logout</pre><br />
<br />
Switch to <code>/opt</code> directory<br />
<pre>$ cd /opt</pre><br />
<br />
I had to install git on my Ubuntu system<br />
<pre>$ sudo apt install git</pre><br />
<br />
Clone Factorio init script from github<br />
<pre>$ sudo git clone https://github.com/Bisa/factorio-init.git<br />
Cloning into 'factorio-init'...<br />
remote: Enumerating objects: 1028, done.<br />
remote: Counting objects: 100% (145/145), done.<br />
remote: Compressing objects: 100% (71/71), done.<br />
remote: Total 1028 (delta 70), reused 121 (delta 60), pack-reused 883<br />
Receiving objects: 100% (1028/1028), 265.92 KiB | 2.95 MiB/s, done.<br />
Resolving deltas: 100% (584/584), done.<br />
anon@steamnuc00:/opt$ git --version<br />
git version 2.25.1</pre><br />
<br />
Validate factorio-init directory exists<br />
<pre>$ ls -l /opt<br />
drwxr-xr-x 8 steamy steamy 4096 Sep 4 14:53 factorio<br />
drwxr-xr-x 5 root root 4096 Sep 4 15:00 factorio-init</pre><br />
<br />
Change ownership to Factorio user<br />
<br />
<pre>$ sudo chown -R steamy:steamy /opt/factorio-init/</pre><br />
<br />
Edit config.example and add your Factorio users.<br />
<br />
<pre>$ sudo vi /opt/factorio-init/config.example</pre><br />
<br />
Here are my edits to config.example after making edits<br />
<pre>$ grep -i steamy factorio-init/config.example <br />
USERNAME=steamy<br />
USERGROUP=steamy</pre><br />
<br />
Edit factorio.service.example with your default values<br />
<br />
<pre>$ sudo vi /opt/factorio-init/extras/factorio.service.example</pre><br />
<br />
Here are my edits to factorio.service.example after making edits<br />
<br />
<pre>$ grep -i steamy /opt/factorio-init/extras/factorio.service.example<br />
User=steamy<br />
Group=steamy</pre><br />
<br />
Make Factorio start on operating system boot and restart if failure (configurable - I kept defaults for now)<br />
<pre>$ sudo cp /opt/factorio-init/extras/factorio.service.example /etc/systemd/system/factorio.service<br />
$ sudo systemctl daemon-reload</pre><br />
<br />
Sysvinit<br />
<pre>$ sudo ln -s /opt/factorio-init/factorio /etc/init.d/factorio<br />
$ sudo chmod +x /opt/factorio-init/factorio</pre><br />
<br />
Show help<br />
<pre>$ service factorio help<br />
Usage: /etc/init.d/factorio COMMAND<br />
<br />
Available commands:<br />
start Starts the server<br />
stop Stops the server<br />
restart Restarts the server<br />
status Displays server status<br />
players-online Shows online players<br />
players Shows all players<br />
cmd [command/message] Open interactive commandline or send a single command to the server<br />
log [--tail|-t] Print the full server log, optionally tail the log to follow in real time<br />
chatlog [--tail|-t] Print the current chatlog, optionally tail the log to follow in real time<br />
new-game name [map-gen-settings] [map-settings] Stops the server and creates a new game with the specified<br />
name using the specified map gen settings and map settings json files<br />
save-game name Stops the server and saves game to specified save<br />
load-save name Stops the server and loads the specified save<br />
install [tarball] Installs the server with optional specified tarball<br />
(omit to download and use the latest headless server from Wube)<br />
update [--dry-run] Updates the server<br />
invocation Outputs the invocation for debugging purpose<br />
listcommands List all init-commands<br />
listsaves List all saves<br />
version Prints the binary version<br />
mod Manage mods (see /etc/init.d/factorio mod help for more information)<br />
help Shows this help message</pre><br />
<br />
Setup Autocompletion<br />
<pre>$ sudo ln -s /opt/factorio-init/extras/bash_autocomplete /etc/bash_completion.d/factorio<br />
$ sudo ln -s /opt/factorio-init/factorio /usr/local/bin/factorio</pre><br />
<br />
Copy example server settings (make any changes you want to copy)<br />
<pre>$ sudo cp /opt/factorio/data/server-settings.example.json /opt/factorio/data/server-settings.json</pre><br />
<br />
Copy example configuration (make any changes you want to copy)<br />
<pre>robot01@apu01:/opt/factorio$ sudo cp /opt/factorio-init/config.example /opt/factorio-init/config</pre><br />
<br />
Make any changes to config ini<br />
<pre>robot01@apu01:/opt/factorio$ sudo vi /opt/factorio/config/config.ini</pre><br />
<br />
=== Update headless server ===<br />
<br />
download latest headless version<br />
<br />
unzip and untar<br />
<br />
<pre>sudo tar -xJf linux64</pre><br />
<br />
change permissions to your dedicated factorio user<br />
<br />
<pre>sudo chown -R steamy:steamy factorio</pre><br />
<br />
launch game<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Personal_Computer&diff=3054Personal Computer2023-09-02T22:44:20Z<p>Paul: /* Household Personal Computers */</p>
<hr />
<div>Hardware, software and accessories that are used on personal computers.<br />
<br />
I use [http://www.newegg.com/ NewEgg] for about 95% of my computer related purchases and [http://www.microcenter.com MicroCenter] and [http://www.amazon.com/ Amazon] for the remaining 5%. NewEgg service, price, and website interface leave the others in the dust.<br />
<br />
== Household Personal Computers ==<br />
<br />
When I remember I keep this up-to-date.<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
|-<br />
! Nickname<br />
! Primary User<br />
! CPU<br />
! Memory<br />
! Video Adapters<br />
! Storage Devices<br />
! Monitors<br />
! Power Supply<br />
! Motherboard<br />
! Case<br />
! Operating System<br />
|-<br />
| sourdough<br />
| daddy<br />
| i7-7700K Kaby Lake @ 4.2 GHz<br />
| 32GB(2x16)<br />
| Two EVGA GeForce GTX 1070 SC GAMING ACX 3.0 8GB (SLI)<br />
| Intel SSD 600p + 1 TB HDD<br />
| Three 23" Dell LCD + 1 Acer 23" accessory<br />
| CORSAIR RM750X 750W 80 PLUS GOLD<br />
| ASUS ROG STRIX Z270H<br />
| Cooler Master HAF 912<br />
| Win 10 64-bit<br />
|-<br />
| frog<br />
| mommy<br />
| AMD FX-6350 Six-Core @ 3.9GHz <br />
| 16GB(4x4)<br />
| One XFX R9-270X-CDFC Radeon R9 270X<br />
| One Seagate 7200RPM 1TB HDD 64MB cache<br />
| Acer G6 G246HLAbd 24" LED<br />
| Corsair HX 850<br />
| ASUS SABERTOOTH 990FX R2.0 <br />
| Cooler Master HAF 912<br />
| Win 10 64-bit<br />
|-<br />
| irish<br />
| 13-year old daughter<br />
| AMD FX-8350 Black Edition Vishera 8-Core @ 4.0GHz<br />
| 32GB (4 x 8GB) DDR3 1866<br />
| EVGA NVidia GTX 560Ti<br />
| One Seagate 1TB 7200 RPM <br />
| One 23" Dell LCD<br />
| Corsair HX 750<br />
| ASUS SABERTOOTH 990FX R2.0 AM3+ AMD 990FX<br />
| Cooler Master HAF 922<br />
| Win 10 64-bit<br />
|-<br />
| elephant<br />
| 11-year old daughter<br />
| i5-4690 @ 3.5 GHz<br />
| 32GB(4x8)<br />
| EVGA GeForce GTX 770 4GB<br />
| One 2TB HDD<br />
| Three 23" Dell LCD + 1 HP 23" accessory<br />
| Corsair HX 1050<br />
| ASUS Sabertooth Z97 Mark1<br />
| Cooler Master HAF 932 Advanced RC-932-KKN5-GP<br />
| Win 10 64-bit<br />
|- <br />
| spiderman<br />
| 8-year old son<br />
| AMD FX-8150 Quad-core @ 3.6GHz<br />
| 16GB(4x4)<br />
| One XFX FX-785A-CDFC Radeon HD 7850 2GB<br />
| Western Digital 1TB HDD<br />
| One 23" Dell LCD<br />
| Corsair HX 850<br />
| MSI 990FXA-GD80 V2<br />
| generic<br />
| Win 10 64-bit & Linux Mint w/Cinnamon<br />
|-<br />
| koala<br />
| 6-year old son<br />
| AMD FX-8150 Eight-Core @ 3.6GHz <br />
| 32GB (4x8)<br />
| One XFX FX-785A-CDFC Radeon HD 7850 2GB<br />
| One 1TB HDD<br />
| One 23" Dell LCD<br />
| XFX PRO850W XXX Edition Semi-Modular<br />
| ASUS SABERTOOTH 990FX R2.0 <br />
| Silverstone<br />
| Win 10 64-bit & Linux Mint w/Cinnamon<br />
|-<br />
| shark<br />
| daddy<br />
| AMD FX-8150 Eight-Core @ 3.6GHz<br />
| 32GB(4x8)<br />
| Two XFX FX-785A-CDFC Radeon HD 7850 2GB (Eyefinity @ 5760 x 1080)<br />
| Samsung 256GB SDD<br />
| Three 23" Dell LCD (Eyefinity)<br />
| Corsair HX 1050<br />
| ASUS SABERTOOTH 990FX R2.0<br />
| Cooler Master HAF 932 Advanced RC-932-KKN5-GP<br />
| Win 10 64-bit & Linux Mint w/MATE<br />
|-<br />
| hammerhead<br />
| daddy<br />
| Intel Core i5-6600 6M Skylake Quad-Core 3.3 GHz<br />
| 32GB (4x8GB) 288-Pin DDR4 SDRAM DDR4 2133 (PC4 17000)<br />
| Built-In Intel<br />
| Samsung 950Pro SSD<br />
| Acer H6 H236HL 23"<br />
| Coolmaster GX 750W<br />
| SABERTOOTH Z170 MARK 1<br />
| Antec full tower<br />
| Linux Fedora Core Release 23 64-bit<br />
|-<br />
| steamnuc<br />
| daddy<br />
| Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz<br />
| 16GB (2 x 8GB 260Pin SO-DIMM DDR4 2133)<br />
| Intel Iris Plus Graphics 650<br />
| Samsung 950Pro SSD<br />
| Headless<br />
| Built-in<br />
| Built-in<br />
| NUC7I7BNH<br />
| Linux Ubuntu 20.04.6 LTS <br />
|}<br />
<br />
== Home Network ==<br />
<br />
=== WAN connectivity ===<br />
<br />
Our house uses both Google Fiber and AT&T Fiber at 1 Gbps synchronous Internet. I get approximately 945 Mbps for upload and 945 Mbps for download on Google Fiber. AT&T Fiber is approximately 840 Mbps download and 940 Mbps upload.<br />
<br />
For residential homes Google Fiber only offers dynamic IP address assignment (my IP has changed once in over 3 years). AT&T Fiber has better IP address options than Google Fiber. AT&T doesn't care whether your fiber connection is residential or business. AT&T Gigabit Fiber offers [https://www.att.com/esupport/article.html#!/u-verse-high-speed-internet/KM1002300?gsi=_Wmcnv4 static IP addresses]. The AT&T Fiber cost per month is $15 for block of 8, $25 for 16, $30 for 32, $35 for 64, and $40 for 128.<br />
<br />
=== LAN connectivity ===<br />
<br />
Our house has a 1 Gbps wired network over Unshielded Twisted Pair (UTP) CAT5E with face plates installed in various rooms. The wires connect to a 24-port patch panel. The 24-port patch panel connects to a 24-port non-managed Gigabit switch.<br />
<br />
== Old notes regarding some computer issues ==<br />
<br />
=== Marvell 91xx Config ATA Device ===<br />
<br />
'''Issue:'''<br />
<br />
BIOS defaults to IDE Mode and I changed to AHCI Mode. Windows found standard AHCI 1.0 Serial ATA Controller and ATA Channel 0 through 7. The Marvell driver failed and I got a "No driver found" for Marvell 91xx Config ATA Device.<br />
<br />
'''Screen capture (no driver):'''<br />
<br />
[[File:marvellNoDriver.png]]<br />
<br />
'''Fix:'''<br />
<br />
I downloaded Marvell 91XX Controller Beta Driver V1.2.0.1002 for Windows 32/64bit Vista & 32/64bit Windows 7.(WHQL) Beta Version 1.2.0.1002 from [http://support.asus.com/Download/Options.aspx ASUS support] page then installed it. Windows 7 did not even require a reboot and drive has been found.<br />
<br />
'''Screen capture (driver installed):'''<br />
<br />
[[File:marvellDriverInstalled.png]]<br />
<br />
[http://www.intel.com/p/en_US/support/highlights/dsktpboards/dx48bt2 Intel DX48BT2] motherboard support site<br />
<br />
== Software ==<br />
<br />
=== Office Suite ===<br />
<br />
[http://www.libreoffice.org/ Libre Office]<br />
<br />
=== Image or graphic tools ===<br />
<br />
Use [https://imagemagick.org/ ImageMagick®] to create, edit, compose, or convert bitmap images. It can read and write images in a variety of formats (over 200) including PNG, JPEG, GIF, HEIC, TIFF, DPX, EXR, WebP, Postscript, PDF, and SVG. Use ImageMagick to resize, flip, mirror, rotate, distort, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves.<br />
<br />
ImageMagick is free software delivered as a ready-to-run binary distribution or as source code that you may use, copy, modify, and distribute in both open and proprietary applications. It is distributed under a derived Apache 2.0 license.<br />
<br />
ImageMagick utilizes multiple computational threads to increase performance and can read, process, or write mega-, giga-, or tera-pixel image sizes.<br />
<br />
==== Vector graphics ====<br />
<br />
[https://inkscape.org/en/about/ Inkscape] is professional quality vector graphics software that runs on Windows, Mac OS X and GNU/Linux. It is used by design professionals and hobbyists worldwide, for creating a wide variety of graphics such as illustrations, icons, logos, diagrams, maps and web graphics. Inkscape uses the W3C open standard SVG (Scalable Vector Graphics) as its native format, and is free and open-source software.<br />
<br />
=== CD / DVD Burning software ===<br />
<br />
To burn data and audio CD / DVDs I use [http://cdburnerxp.se/ CD BurnerXP].<br />
<br />
To create personal copies of protected DVDs that I have purchased I use [http://www.1clickdvdcopy.com/1clickdvdcopypro.asp 1ClickDVDCopy Pro] ($79 fee) and [http://www.dvd43.com/ DVD43], a free decrypter.<br />
<br />
=== Multimedia software ===<br />
<br />
[http://www.videolan.org/vlc/ VLC] - the cross-platform media player and streaming server.<br />
<br />
VLC media player is a highly portable multimedia player for various audio and video formats (MPEG-1, MPEG-2, MPEG-4, DivX, mp3, ogg, ...) as well as DVDs, VCDs, and various streaming protocols. It can also be used as a server to stream in unicast or multicast in IPv4 or IPv6 on a high-bandwidth network.<br />
<br />
==== Video Capture ====<br />
<br />
[http://www.fraps.com/ Fraps] is a universal Windows application that can be used with games using DirectX or OpenGL graphic technology. In its current form Fraps performs many tasks and can best be described as:<br />
* Benchmarking Software <br />
* Screen Capture Software<br />
* Realtime Video Capture Software<br />
<br />
<br />
==== Video Editing ====<br />
<br />
[https://www.mp4joiner.org/en/ MP4Tools] is a collection of cross-platform free tools to manipulate MP4 files. It contains following applications:<br />
<br />
*MP4Joiner is a free application that allows join multiple MP4 files into one without reencoding and without quality loss.<br />
*MP4Splitter is a free application that allows split a MP4 file in multiple files without reencoding and without quality loss<br />
<br />
MP4Tools is Open Source Software and is completely free.<br />
<br />
[http://www.freemake.com/ Freemake] offers freeware in the truest sense of the word: no feature or time limitations, no hidden costs. Download and use our free Video Converter, Video Downloader, Audio Converter and Free Music Box! Convert video free to AVI, MP4, WMV, MKV, FLV, 3GP, MPEG, DVD, Blu-ray, MP3, iPod, iPhone, iPad, PSP, Android, Nokia, Samsung, BlackBerry with [http://www.freemake.com/free_video_converter/ Free Video Converter]. Convert audio free to MP3, WMA, WAV, FLAC, AAC, M4A, OGG, convert audio to MP3 player, iPod, iPhone, iPad, PSP, and more with our [http://www.freemake.com/free_audio_converter/ Free Audio Converter].<br />
<br />
<pre>I like FreeMake products as the software is simple to use & their site provides video tutorials.<br />
Their products work, have lots of features, & no hidden spyware or adware.</pre><br />
<br />
<br />
[http://www.tmpgenc.net/en/index.html TMPGEnc] converts *.AVI files to MPEG1, the format which is used in VideoCDs. Using a variety of options in TMPGEnc, you can compress your video file in high quality.<br />
<br />
TMPGEnc enables you to adjust bitrate, quantize matrix, GOP structure, interlacing and many other parameters so that you can create the most appropriate movie file depending on your needs.<br />
<br />
[http://www.virtualdub.org/ Virtualdub]is a video capture/processing utility for 32-bit and 64-bit Windows platforms (98/ME/NT4/2000/XP/Vista/7), licensed under the GNU General Public License (GPL). It lacks the editing power of a general-purpose editor such as Adobe Premiere, but is streamlined for fast linear operations over video. It has batch-processing capabilities for processing large numbers of files and can be extended with third-party video filters.<br />
<br />
=== Communications Software ===<br />
<br />
==== Browser and E-mail ====<br />
<br />
[http://www.mozilla.com/en-US/ Firefox and Thunderbird]<br />
<br />
[[My Thunderbird Notes]]<br />
<br />
===== Firefox add-ons =====<br />
<br />
FireFTP<br />
<br />
Download Status Bar<br />
<br />
[http://www.zotero.org/ Zotero] is a free, easy-to-use Firefox extension to help you collect, manage, cite, and share your research sources. It lives right where you do your work—in the web browser itself.<br />
<br />
==== Torrent ====<br />
<br />
[http://www.qbittorrent.org/ qBittorrent] project aims to provide a '''free software''' alternative to µtorrent. Additionally, qBittorrent runs and provides the same features on all major platforms (Linux, Mac OS X, Windows, OS/2, FreeBSD).<br />
<br />
==== Java ====<br />
<br />
[http://www.java.com/en/download/manual.jsp Java]<br />
<br />
==== FTP clients ====<br />
<br />
[http://filezilla-project.org/ Filezilla]<br />
<br />
==== VoIP clients ====<br />
<br />
[http://www.ventrilo.com/ Ventrillo]<br />
<br />
[http://www.goteamspeak.com/ TeamSpeak]<br />
<br />
==== IRC client ====<br />
<br />
[http://hexchat.github.io/index.html HexChat]<br />
<br />
==== SSHv2 & SFTP ====<br />
<br />
I switched to [https://www.bitvise.com/ssh-client Bitvise SSH client] for SSH client. I like some of the features Bitvise offers. [http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty] is a free SSHv2 program. You can also get SecureFTP program from same site.<br />
<br />
[http://www.mremoteng.org/ mRemoteNG] is a fork of mRemote, an open source, tabbed, multi-protocol, remote connections manager. mRemoteNG adds bug fixes and new features to mRemote.<br />
<br />
eRemoteNG allows you to view all of your remote connections in a simple yet powerful tabbed interface.<br />
<br />
mRemoteNG supports the following protocols:<br />
* RDP (Remote Desktop/Terminal Server)<br />
* VNC (Virtual Network Computing)<br />
* ICA (Citrix Independent Computing Architecture)<br />
* SSH (Secure Shell version 1 & 2)<br />
* Telnet (TELecommunication NETwork)<br />
* HTTP/HTTPS (Hypertext Transfer Protocol)<br />
* rlogin<br />
* Raw Socket Connections<br />
<br />
==== Tunnelier ====<br />
<br />
[http://www.bitvise.com/tunnelier Bitvise Tunnelier]<br />
<br />
=== Utilities ===<br />
<br />
==== Console utilities ====<br />
<br />
[https://cmder.net/ Cmder] is a software package created out of pure frustration over the absence of nice console emulators on Windows. It is based on amazing software, and spiced up with the Monokai color scheme and a custom prompt layout, looking sexy from the start.<br />
<br />
[https://conemu.github.io/ ConEmu-Maximus5] aims to be handy, comprehensive, fast and reliable terminal window where you may host any console application developed either for WinAPI (cmd, powershell, far) or Unix PTY (cygwin, msys, wsl bash).<br />
<br />
[https://github.com/cmderdev/cmder/wiki/How-to-start-Cmder-from-anywhere Steps to put Cmder in your environment variable]<br />
<br />
==== eBook ====<br />
<br />
[http://calibre-ebook.com/about calibre] is a free and open source e-book library management application developed by users of e-books for users of e-books. It has a cornucopia of features divided into the following main categories:<br />
<br />
* Library Management<br />
* E-book conversion<br />
* Syncing to e-book reader devices<br />
* Downloading news from the web and converting it into e-book form<br />
* Comprehensive e-book viewer<br />
* Content server for online access to your book collection<br />
<br />
==== Screen Capture ====<br />
<br />
In December of 2017 I switched my entire family over to [http://getgreenshot.org/ Greenshot] for screen capture software. With each new version of SnagIt the user interface kept getting worse. Not only is Greenshot free I actually like using it more than SnagIt. I have been using TechSmith's SnagIt for many years and with each newer version of SnagIt I had to buy another copy and the program got worse due to added complexity and bloat.<br />
<br />
[https://www.techsmith.com/snagit.html Snagit] by TechSmith<br />
<br />
'''Note on Snagit version 12.4.1''' I noticed a TechSmith Uploader Service taking up 1.7 MB of RAM. I contacted TechSmith support and explained what the service did and how to remove it.<br />
<br />
'''Purpose:''' The TechSmith Uploader Service is used when Snagit is integrated with TechSmith Relay, which is an Enterprise service that we offer. The service is designed to run in the background and not be visible to the user.<br />
<br />
'''Removal:''' Remove TechSmith Uploader Service by browsing to C:\Program Files (x86)\Common Files\TechSmith Shared\Uploader on your computer. Right click on the "UninstallAndRemoveUploader.cmd" file and choose Run as administrator. Once that is done reboot your machine.<br />
<br />
==== Password manager ====<br />
<br />
[http://keepass.info/ Keepass] is a free open source password manager, which helps you to manage your passwords in a secure way. You can put all your passwords in one database, which is locked with one master key or a key file. So you only have to remember one single master password or select the key file to unlock the whole database. The databases are encrypted using the best and most secure encryption algorithms currently known (AES and Twofish). For more information, see the [http://keepass.info/features.html features page].<br />
<br />
==== PDF Viewer & Printer ====<br />
<br />
[http://www.foxitsoftware.com/pdf/rd_intro.php Foxit Reader] Foxit Reader is a free PDF document viewer and printer, with incredible small size (only 2.55 M download size), breezing-fast launch speed and rich feature set. Foxit Reader supports Windows Me/2000/XP/2003/Vista. Its core function is compatible with PDF Standard 1.7.<br />
<br />
==== Compression ====<br />
<br />
===== Open Source =====<br />
<br />
[http://peazip.sourceforge.net/ Peazip] Note: Ensure you read install directions carefully to avoid extra software (crapware?)<br />
<br />
===== Closed source =====<br />
[http://www.rarlab.com/ WinRAR]<br />
<br />
==== Backup ====<br />
<br />
MozBackup is a simple utility for creating backups of Mozilla Firefox, Mozilla Thunderbird, Mozilla Sunbird, Flock, SeaMonkey, Mozilla Suite, Spicebird and Netscape profiles.<br />
<br />
[http://mozbackup.jasnapaka.com/ MozBackup]<br />
<br />
==== Hardware Monitor ====<br />
<br />
[http://www.almico.com/speedfan.php SpeedFan] is a program that monitors voltages, fan speeds and temperatures in computers with hardware monitor chips. SpeedFan can even access S.M.A.R.T. info for those hard disks that support this feature and show hard disk temperatures too, if supported.<br />
<br />
==== GPU Utilities ====<br />
<br />
[http://www.radeonpro.info/en-US/ RadeonPro]<br />
<br />
==== HASH utilities ====<br />
<br />
Use [https://wiki.gotopinion.info/wiki/index.php?title=Windows_Operating_System#HASH_in_PowerShell PowerShell built-in command]<br />
<br />
Command line [https://kanguru.zendesk.com/entries/21747773-SHA256-Checksum-Utility SHA256 Checksum Utility] for Windows<br />
<br />
=== Voxel utilities ===<br />
<br />
[https://ephtracy.github.io/index.html MagicaVoxel] is a free lightweight 8-bit voxel art editor and GPU based interactive path tracing render-er.<br />
<br />
[https://ephtracy.github.io/index.html?page=mv_controls MagicaVoxel] keyboard shortcuts.<br />
<br />
===== Tutorials =====<br />
<br />
[https://www.megavoxels.com/2019/08/magicavoxel-3d-art-tutorial-for.html MagicaVoxel 3D Art Tutorial for Beginners]<br />
<br />
== Accessories ==<br />
<br />
=== Mouse pads ===<br />
<br />
[http://www.xtracpads.com/ XTracPads]<br />
<pre>Prefer Xtracpads</pre><br />
<br />
[http://www.ratpadz.com/ RatPadz]<br />
<pre>Second choice is RatPadz. Over the years my Ratpadz start to fail<br />
as the surface becomes worn & smooth in areas which impacts laser mouse<br />
movement</pre><br />
<br />
=== To Go ===<br />
<br />
[http://www.geargrip.com/index.php Gear Grip]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Default_Avorion_server.ini_contents&diff=3053Default Avorion server.ini contents2023-09-02T22:23:29Z<p>Paul: </p>
<hr />
<div>$ cat server.ini<br />
<br />
<pre>[Game]<br />
Scenario=1<br />
Seed=Y43CDQoeSa<br />
Difficulty=0<br />
HardcoreEnabled=false<br />
InfiniteResources=false<br />
PlayTutorial=false<br />
CollisionDamage=1<br />
SafePlayerInput=false<br />
PlayerToPlayerDamage=true<br />
LogoutInvincibility=true<br />
LogoutInvincibilityDelay=30<br />
ShipyardBoundBuilding=true<br />
FullBuildingUnlocked=false<br />
RepairingAlwaysAllowed=false<br />
BlockOverlapExploit=false<br />
PermaDestruction=false<br />
DockingRestrictions=true<br />
Barrier=true<br />
Storyline=true<br />
UnlimitedProcessingPower=false<br />
UnlimitedShipSize=false<br />
RelationLossFactor=1<br />
RelationGainFactor=1<br />
StartingResources=0<br />
DamageMultiplier=0.600000024<br />
InitialRelations=0<br />
MapFactions=350<br />
Rifts=200<br />
ResourceAsteroidFactor=1<br />
ResourceWreckageFactor=1<br />
EventsFactor=1<br />
PreciseAIAim=false<br />
BlockDestructionThreshold=0.800000012<br />
DevMode=false<br />
ExplicitCallables=true<br />
RiftMassFactor=1<br />
RiftDamageFactor=1<br />
BigWreckageDespawnTime=1800<br />
SmallWreckageDespawnTime=900<br />
MaximumFightersPerSectorAndPlayer=-1<br />
MaximumStationsPerSector=-1<br />
MaximumBlocksPerCraft=-1<br />
MaximumVolumePerShip=-1<br />
MaximumVolumePerStation=-1<br />
MaximumPlayerShips=-1<br />
MaximumPlayerStations=-1<br />
MaximumAllianceShips=-1<br />
MaximumAllianceStations=-1<br />
MaximumAllianceShipsPerMember=-1<br />
MaximumAllianceStationsPerMember=-1<br />
MaximumBlocksPerTurret=250<br />
BoardingAllowed=true<br />
MinimumCraftSize=0<br />
MaxShipVelocity=0<br />
PlayerInventorySlots=1000<br />
AllianceInventorySlots=1000<br />
Version=2.3.1<br />
sameStartSector=true<br />
xsotanInvasionSectors=5<br />
startUpScript=data/scripts/server/server.lua<br />
startSectorScript=startsector<br />
motd=<br />
[System]<br />
MaxTimeStep=1<br />
saveInterval=600<br />
sectorUpdateTimeLimit=300<br />
emptySectorUpdateInterval=0.5<br />
workerThreads=3<br />
generatorThreads=2<br />
scriptBackgroundThreads=2<br />
aliveSectorsPerPlayer=5<br />
weakUpdate=true<br />
profiling=false<br />
sendCrashReports=true<br />
hangDetection=true<br />
backups=true<br />
backupsPath=<br />
statsLogging=true<br />
simulateHighLoadServer=false<br />
commandsFile=<br />
sendSectorDelay=2<br />
placeInShipOnDeathDelay=7<br />
respawnAloneDelay=12<br />
respawnMultiplayerDelay=92<br />
autoSavePerformanceData=false<br />
performanceDataAutoSaveFiles=10<br />
timeBetweenPerformanceDataAutoSaves=30<br />
fileClustering=false<br />
clusterFileSize=200000000<br />
clusteringThreads=8<br />
[Networking]<br />
port=27000<br />
broadcastInterval=5<br />
isMultiplayer=true<br />
isListed=false<br />
vacSecure=true<br />
sendStatsToAdmins=true<br />
useSteam=true<br />
forceSteam=false<br />
rconIp=<br />
rconPassword=<br />
rconPort=27015<br />
maxReceivableMessageSize=52428800<br />
networkingThreads=2<br />
[Administration]<br />
maxPlayers=10<br />
name=Avorion Server<br />
description=An Avorion Server<br />
password=<br />
pausable=false<br />
accessListMode=Blacklist<br />
steamIdOverride=0<br />
[Meta]<br />
branch=</pre><br />
<br />
<center>[[My Avorion Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Default_Avorion_server.ini_contents&diff=3052Default Avorion server.ini contents2023-09-02T22:18:00Z<p>Paul: </p>
<hr />
<div>$ cat server.ini<br />
<br />
<pre>[Game] <br />
Scenario=1 <br />
Seed=Y43CDQoeSa <br />
Difficulty=0 <br />
HardcoreEnabled=false <br />
InfiniteResources=false <br />
PlayTutorial=false <br />
CollisionDamage=1 <br />
SafePlayerInput=false <br />
PlayerToPlayerDamage=true <br />
LogoutInvincibility=true <br />
LogoutInvincibilityDelay=30 <br />
ShipyardBoundBuilding=true <br />
FullBuildingUnlocked=false <br />
RepairingAlwaysAllowed=false <br />
BlockOverlapExploit=false <br />
PermaDestruction=false <br />
DockingRestrictions=true <br />
Barrier=true <br />
Storyline=true <br />
UnlimitedProcessingPower=false <br />
UnlimitedShipSize=false <br />
RelationLossFactor=1 <br />
RelationGainFactor=1 <br />
StartingResources=0 <br />
DamageMultiplier=0.600000024 <br />
InitialRelations=0 <br />
MapFactions=350 <br />
Rifts=200 <br />
ResourceAsteroidFactor=1<br />
ResourceWreckageFactor=1<br />
EventsFactor=1<br />
PreciseAIAim=false<br />
BlockDestructionThreshold=0.800000012<br />
DevMode=false<br />
ExplicitCallables=true<br />
RiftMassFactor=1<br />
RiftDamageFactor=1<br />
BigWreckageDespawnTime=1800<br />
SmallWreckageDespawnTime=900<br />
MaximumFightersPerSectorAndPlayer=-1<br />
MaximumStationsPerSector=-1<br />
MaximumBlocksPerCraft=-1<br />
MaximumVolumePerShip=-1<br />
MaximumVolumePerStation=-1<br />
MaximumPlayerShips=-1<br />
MaximumPlayerStations=-1<br />
MaximumAllianceShips=-1<br />
MaximumAllianceStations=-1<br />
MaximumAllianceShipsPerMember=-1<br />
MaximumAllianceStationsPerMember=-1<br />
MaximumBlocksPerTurret=250<br />
BoardingAllowed=true<br />
MinimumCraftSize=0<br />
MaxShipVelocity=0<br />
PlayerInventorySlots=1000<br />
AllianceInventorySlots=1000<br />
Version=2.3.1<br />
sameStartSector=true<br />
xsotanInvasionSectors=5<br />
startUpScript=data/scripts/server/server.lua<br />
startSectorScript=startsector<br />
motd=<br />
[System]<br />
MaxTimeStep=1<br />
saveInterval=600<br />
sectorUpdateTimeLimit=300<br />
emptySectorUpdateInterval=0.5<br />
workerThreads=3<br />
generatorThreads=2<br />
scriptBackgroundThreads=2<br />
aliveSectorsPerPlayer=5<br />
weakUpdate=true<br />
profiling=false<br />
hangDetection=true<br />
backups=true<br />
backupsPath=<br />
statsLogging=true<br />
simulateHighLoadServer=false<br />
commandsFile=<br />
sendSectorDelay=2<br />
placeInShipOnDeathDelay=7 <br />
respawnAloneDelay=12<br />
respawnMultiplayerDelay=92<br />
autoSavePerformanceData=false<br />
performanceDataAutoSaveFiles=10<br />
timeBetweenPerformanceDataAutoSaves=30<br />
fileClustering=false<br />
clusterFileSize=200000000 <br />
clusteringThreads=8<br />
[Networking]<br />
port=27000<br />
broadcastInterval=5<br />
isMultiplayer=true<br />
isListed=false<br />
vacSecure=true<br />
sendStatsToAdmins=true<br />
useSteam=true<br />
forceSteam=false<br />
rconIp=<br />
rconPassword=<br />
rconPort=27015<br />
maxReceivableMessageSize=52428800<br />
networkingThreads=2<br />
[Administration]<br />
maxPlayers=10<br />
name=Avorion Server<br />
description=An Avorion Server<br />
password=<br />
pausable=false<br />
accessListMode=Blacklist<br />
steamIdOverride=0<br />
[Meta]<br />
branch=</pre><br />
<br />
<center>[[My Avorion Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Default_Avorion_server.ini_contents&diff=3051Default Avorion server.ini contents2023-09-02T22:00:29Z<p>Paul: initial page creation</p>
<hr />
<div>$ cat server.ini<br />
<br />
<pre>MaximumAllianceStations=-1<br />
MaximumAllianceShipsPerMember=-1<br />
MaximumAllianceStationsPerMember=-1<br />
MaximumBlocksPerTurret=250<br />
BoardingAllowed=true<br />
MinimumCraftSize=0<br />
MaxShipVelocity=0<br />
PlayerInventorySlots=1000<br />
AllianceInventorySlots=1000<br />
Version=2.3.1<br />
sameStartSector=true<br />
xsotanInvasionSectors=5<br />
startUpScript=data/scripts/server/server.lua<br />
startSectorScript=startsector<br />
motd=<br />
[System]<br />
MaxTimeStep=1<br />
saveInterval=600<br />
sectorUpdateTimeLimit=300<br />
emptySectorUpdateInterval=0.5<br />
workerThreads=3<br />
generatorThreads=2<br />
scriptBackgroundThreads=2<br />
aliveSectorsPerPlayer=5<br />
weakUpdate=true<br />
profiling=false<br />
hangDetection=true<br />
backups=true<br />
backupsPath=<br />
statsLogging=true<br />
simulateHighLoadServer=false<br />
commandsFile=<br />
sendSectorDelay=2<br />
placeInShipOnDeathDelay=7 <br />
respawnAloneDelay=12<br />
respawnMultiplayerDelay=92<br />
autoSavePerformanceData=false<br />
performanceDataAutoSaveFiles=10<br />
timeBetweenPerformanceDataAutoSaves=30<br />
fileClustering=false<br />
clusterFileSize=200000000 <br />
clusteringThreads=8<br />
[Networking]<br />
port=27000<br />
broadcastInterval=5<br />
isMultiplayer=true<br />
isListed=false<br />
vacSecure=true<br />
sendStatsToAdmins=true<br />
useSteam=true<br />
forceSteam=false<br />
rconIp=<br />
rconPassword=<br />
rconPort=27015<br />
maxReceivableMessageSize=52428800<br />
networkingThreads=2<br />
[Administration]<br />
maxPlayers=10<br />
name=Avorion Server<br />
description=An Avorion Server<br />
password=<br />
pausable=false<br />
accessListMode=Blacklist<br />
steamIdOverride=0<br />
[Meta]<br />
branch=</pre><br />
<br />
<center>[[My Avorion Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Avorion_Info&diff=3050My Avorion Info2023-09-02T21:59:34Z<p>Paul: /* Configure Avorion headless server galaxy */</p>
<hr />
<div>== Avorion headless server ==<br />
<br />
These steps were created using Ubuntu 20.04.6 LTS and Avorion server 2.3.1.<br />
<br />
Steps<br />
# Ensure that SteamCMD is installed. The steps to install are [https://developer.valvesoftware.com/wiki/SteamCMD here].<br />
# Create a directory for Avorion headless server application.<br />
# Create a directory for Avorion galaxy files.<br />
# Install Avorion headless server application.<br />
# Start, Save, and Stop Avorion headless server application.<br />
# Update Avorion headless server application.<br />
<br />
For all the steps use your Steam user created for steamcmd. My user is called 'steamy' and the command used to switch to user steamy is:<br />
<br />
<code>$ sudo -u steamy -s</code><br />
<br />
=== Installing Avorion via steamcmd ===<br />
<br />
'''Ensure steamcmd is installed.'''<br />
<br />
=== Create directory for Avorion headless server application ===<br />
<br />
I created a directory called Avorion in the user steamy home directory. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion</code><br />
<br />
=== Create a directory for Avorion galaxy files ===<br />
<br />
I created a directory called Avorion_Galaxies in the user steamy home directory for Avorion headless server app galaxies. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion_Galaxies</code><br />
<br />
=== Install Avorion headless server application ===<br />
<br />
Command format:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir <SERVER_PATH> +app_update 565060 validate +exit</code><br />
<br />
The SERVER_PATH is the absolute path to Avorion headless server application files. The SERVER_PATH for my steps is /home/steamy/Avorion. Command used:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
Result:<br />
<br />
<pre>steamy@steamnuc00:~$ steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit<br />
Redirecting stderr to '/home/steamy/.steam/logs/stderr.txt'<br />
[ 0%] Checking for available updates...<br />
[----] Verifying installation...<br />
Steam Console Client (c) Valve Corporation - version 1691628584<br />
-- type 'quit' to exit --<br />
Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory<br />
OK<br />
<br />
Connecting anonymously to Steam Public...OK<br />
Waiting for client config...OK<br />
Waiting for user info...OK<br />
Please use force_install_dir before logon!<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x61) downloading, progress: 4.61 (6291456 / 136420041)<br />
Update state (0x61) downloading, progress: 27.83 (37970732 / 136420041)<br />
Update state (0x61) downloading, progress: 50.12 (68379436 / 136420041)<br />
Update state (0x61) downloading, progress: 70.63 (96351157 / 136420041)<br />
Update state (0x61) downloading, progress: 93.85 (128031433 / 136420041)<br />
Success! App '565060' fully installed.<br />
CWorkThreadPool::~CWorkThreadPool: work processing queue not empty: 1 items discarded.<br />
steamy@steamnuc00:~$</pre><br />
<br />
=== Start, Save, and Stop Avorion headless server application ===<br />
<br />
Command:<br />
<br />
<code>./server.sh --galaxy-name <GALAXY_NAME> --admin <64-bit SteamID> --datapath <GALAXY_PATH></code><br />
<br />
GALAXY_NAME is the name of your galaxy. For this setup, I used <code>Andromedia</code>. <span style="color:red">NOTE: If the GALAXY_NAME doesn't exist, this command will create a galaxy with the GALAXY_NAME value.</span><br />
64-bit SteamID is your 64-bit SteamID. For this setup, use your own 64-bit SteamID.<br />
GALAXY_PATH is the directory where you will store your galaxies. I used <code>/home/steamy/Avorion_Galaxies/</code>.<br />
<br />
Command used without my SteamID:<br />
<br />
<code>./server.sh --galaxy-name Andromeda --admin <64-bit SteamID> --datapath /home/steamy/Avorion_Galaxies/</code><br />
<br />
Once your Avorion headless server application is running, type <code>/save</code> to save galaxy or <code>/stop</code> to exit application. <span style="color:blue">It is good practice to always use /save and then /stop.</span><br />
<br />
<span style="color:red">NOTE: Always stop the server by using <code>/stop</code> command. Closing the console window may cause issues with your galaxy or Avorion headless server application files.</span><br />
<br />
=== Configure Avorion headless server galaxy ===<br />
<br />
[[Avorion server.ini README contents]]<br />
<br />
Make any changes to your server.ini you need by editing the server.ini of your galaxy. It is stored at <GALAXY_PATH>/<GALAXY_NAME>. Save the file after making any changes.<br />
<br />
[[Default Avorion server.ini contents]] for Andromedia galaxy created in previous steps.<br />
<br />
Suggest making a backup of server.ini before making changes!<br />
<br />
=== Update Avorion headless server application ===<br />
<br />
To update your Avorion headless server application, run the same command used to install the application.<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
== Avorion game info ==<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Avorion_server.ini_README_contents&diff=3049Avorion server.ini README contents2023-09-02T21:58:38Z<p>Paul: Created page with "A cleaned up version after running <code>$ cat 'server.ini - readme.txt'</code> <pre>CollisionDamage=1 # Collision damage from 0 (off) to 1 (ful..."</p>
<hr />
<div>A cleaned up version after running <code>$ cat 'server.ini - readme.txt'</code><br />
<br />
<pre>CollisionDamage=1 # Collision damage from 0 (off) to 1 (full).<br />
SafePlayerInput=false # Deprecated, don't use this. Verifies player input but may lead to massive (perceived) lags.<br />
PlayerToPlayerDamage=true # Enable to allow players to damage each other.<br />
LogoutInvincibility=true # Enable to turn player ships invincible after a short time after the player logged out.<br />
LogoutInvincibilityDelay=30 # Time in seconds between a player logging out and their ship turning invincible.<br />
ShipyardBoundBuilding=true # Enable to limit building of specific blocks to sectors with shipyards.<br />
FullBuildingUnlocked=false # Full building knowledge unlocked for every new player.<br />
RepairingAlwaysAllowed=false # Repairing is always possible, even in combat.<br />
BlockOverlapExploit=false # Highly recommended to be turned to 'false' for normal play. If enabled, allows exploit ship builds with infinite block overlap. Only left in for pre-2.0 backwards compatibility.<br />
PermaDestruction=false # Reconstruction is disabled, and ships are lost forever on destruction, including turrets and upgrades.<br />
DockingRestrictions=true # If enabled, some objects (like gates) can't be docked and docked entities's turrets require the mothership to have enough slots to be operable.<br />
Barrier=true # Enable/Disable the barrier to the center of the galaxy.<br />
Storyline=true # Enable/Disable the guided storyline. This does not disable artifacts or progression, just the guidance of the player. Artifacts can be collected just like before.<br />
UnlimitedProcessingPower=false # Building Knowledge, if enabled, doesn't limit Processing Power available for ships. You can build your ships as big as you want, even if you don't have the next material knowledge unlocked yet.<br />
UnlimitedShipSize=false # Enable to have ships be built as big, beefy and unbalanced as you want once your ship has reached maximum processing power.<br />
RelationLossFactor=1 # Set to a value other than 1 to add a factor to relation loss. 1.5 would mean 50% more relations lost.<br />
RelationGainFactor=1 # Set to a value other than 1 to add a factor to relation gain. 1.5 would mean 50% more relations gained<br />
StartingResources=0 # Set to a value between -4 and 0 for starting resources (matching the difficulties from -3 to 0). -4 is quick start.<br />
DamageMultiplier=1 # A factor that is multiplied with damage dealt by NPC ships.<br />
InitialRelations=0 # Set to a value between -3 (best relations) to 3 (worst relations) for initial relations simlar to the difficulties.<br />
MapFactions=350 # Sets the amount of factions that are present on the map. Undefined behavior for 0 or less f a lot of cheats and hacks.<br />
RiftMassFactor=1 # Multiplier for the amount of mass that can be taken into rifts. Default is 1, above increases possible mass, below reduces it.<br />
RiftDamageFactor=1 # Multiplier for the amount of damage that Xsotan deal in rifts. Default is 1, above increases damage, below reduces it. Will be multiplied with DamageMultiplier.<br />
BigWreckageDespawnTime=1800 # Amount of time in seconds until large wreckages (16 blocks or more) despawn. Only affects wreckages created by destroying things, not wreckages created by the generator (ie. scrapyards).<br />
SmallWreckageDespawnTime=900 # Amount of time in seconds until small wreckages (15 blocks or less) despawn. Only affects wreckages created by destroying things, not wreckages created by the generator (ie. scrapyards).<br />
MaximumFightersPerSectorAndPlayer=-1 # Maximum allowed number of simultaneous fighters per sector and per player. Set to -1 for no limit.<br />
MaximumStationsPerSector=-1 # Maximum allowed number of stations in a sector. Only checks when players found stations, the generator can exceed the limit. Set to -1 for no limit.<br />
MaximumBlocksPerCraft=-1 # Maximum allowed blocks per player craft. Set to -1 for no limit.<br />
MaximumVolumePerShip=-1 # Maximum allowed volume per player ship. Set to -1 for no limit.<br />
MaximumVolumePerStation=-1 # Maximum allowed volume per player station. Set to -1 for no limit.<br />
MaximumPlayerShips=-1 # Maximum allowed ships per player. Set to -1 for no limit.<br />
MaximumPlayerStations=-1 # Maximum allowed stations per player. Set to -1 for no limit.<br />
MaximumAllianceShips=-1 # Maximum allowed ships per alliance. Set to -1 for no limit.<br />
MaximumAllianceStations=-1 # Maximum allowed stations per alliance. Set to -1 for no limit.<br />
MaximumAllianceShipsPerMember=-1 # Maximum allowed ships per alliance per member. Set to -1 for no limit. If both normal maximum and maximum per member is set, the smaller of the two will be the limit.<br />
MaximumAllianceStationsPerMember=-1 # Maximum allowed stations per alliance per member. Set to -1 for no limit. If both normal maximum and maximum per member is set, the smaller of the two will be the limit.<br />
MaximumBlocksPerTurret=250 # Maximum allowed blocks per player turret design. Set to -1 for no limit.<br />
BoardingAllowed=true # Disable to forbid boarding for all players.<br />
MinimumCraftSize=0 # Set to a value other than 0 to set a minimum craft size. A ship's height, length or width can't be smaller than this value. It's highly recommended to not set this to a value that's bigger than 1.0, as that's the basic ship founding ter of the galaxy.<br />
startUpScript=data/scripts/server/server.lua # Configures the path of the startup script for the server.<br />
startSectorScript=startsector # Configures the path of the start sector generator script for the server.<br />
motd= # Enter a message of the day here that is sent to players as a chat message when logging in.<br />
[System]<br />
MaxTimeStep=1 # Maximum tick length in seconds. When a tick takes more than this long (because of performance problems), it will be shortened to this number to avoid tunneling issues and the like. Don't change this unless you know what you're doing.<br />
saveInterval=600 # Time in seconds. Whenever this much time has passed, the server starts an auto-save and writes all currently loaded data to disk. The saving process may take a few seconds.<br />
sectorUpdateTimeLimit=300 # Default time in seconds that a sector is kept in memory before it's unloaded. A sector is only unloaded when: 1. no player or player content is in it or 2. when it's not connected via gate or wormhole to another sector containing a player. Exception: Newly loaded sectors without players are always kept in memory for at least 15 seconds.<br />
emptySectorUpdateInterval=0.5 # Time in seconds between updates of sectors without players in them.<br />
workerThreads=3 # Number of threads that are used for updating the main game simulation. This should never exceed the amount of virtual cores available.<br />
generatorThreads=2 # Number of threads that will load sectors from disk and generate new sectors while players are exploring. Loading/generating a sector usually takes a few seconds. Recommended number is usually 2, but it is encouraged to increase the number if loading (ie. jump route calculation times) are getting very high.<br />
scriptBackgroundThreads=2 # Number of threads that will be doing asynchronous tasks for script code.<br />
aliveSectorsPerPlayer=5 # Number of sectors beyond a player's current location that are kept in memory. Also applies to alliances while members are logged in.<br />
weakUpdate=true # Performance optimization. Improves performance by doing a simplified simulation of sectors without players.<br />
profiling=false # Enable to track performance data of the server. Might cause the server to run slightly slower (less than 1ms/tick) and use more memory (~100MB). Recommended for debugging if your server experiences low performance. Use /status or /profile commands to print out performance data (viewable in Chrome via chrome://tracing).<br />
sendCrashReports=true # Enable to send crash reports when a script or the server process crashes. Highly recommended.<br />
hangDetection=true # Enable to send crash reports when a script or the server process doesn't respond for at least 30 seconds. Highly recommended.<br />
backups=true # Enable to create hourly backups of the most important data of the server. Creating backups may take a few seconds. Backups will be saved to %appdata%\Avorion\backups (~/.avorion/backups on unix) by default, or to configured backups path.<br />
backupsPath= # Configurable path where the server will save its backups to. Leave empty to save it to the default settings folder.<br />
statsLogging=true # Enable to track server stats over time. The stats are stored in a CSV file in the server directory, similar to logs.<br />
simulateHighLoadServer=false # Enable to simulate a server with irregular update times, similar to high load. This is only relevant for developing mods.<br />
commandsFile= # Configurable path where the server looks for a text file that contains commands. Use to send commands to the server when RCON or signals are unavailable. The commands must be formatted similar to chat commands, ie. "/stop 60" (without quotes). Multiple commands in multiple lines are supported. Commands are only executed when the file has had the same content for<br />
more than 0.5 seconds. Upon reading the commands from the file, the file will be deleted. If this string is empty, the server will look for a file named 'commands.txt' in the galaxy folder.<br />
sendSectorDelay=2 # A delay in seconds until the server sends a new sector to a client upon sector change.<br />
placeInShipOnDeathDelay=7 # Time in seconds that a player will spend without a ship after their ship was destroyed.<br />
respawnAloneDelay=12 # Time in seconds that a player will spend without a ship, before respawning, after their ship was destroyed.<br />
respawnMultiplayerDelay=92 # Time in seconds that a player will spend without a ship, before respawning, while another player is in the sector, after their ship was destroyed.<br />
autoSavePerformanceData=false # Enable to automatically save performance data after bad performance was detected during update. profiling=true is required for this to work.<br />
performanceDataAutoSaveFiles=10 # Amount of performance data files that are kept on disk. When exceeded, the oldest files are deleted.<br />
timeBetweenPerformanceDataAutoSaves=30 # Minimum time in seconds between two automatic performance data printouts.<br />
fileClustering=false # Enables clustering of files. When enabled, server will aggregate small files into larger ones on shutdown. Can increase startup and shutdown times, but reduces amount of files in save.<br />
clusterFileSize=200000000 # Size in bytes of aggregated files. Only relevant if fileClustering is enabled.<br />
clusteringThreads=8 # Amount of threads doing file clustering. Only relevant if fileClustering is enabled. Keep in mind that the server will need [clustered file size] x [threads] amount of free RAM. Many threads also only makes sense when you're not limited by Disk I/O (ie. when your OS supports file caching in memory or you have a RAM FS). Recommended number is at least 2.<br />
[Networking]<br />
port=27000 # Listening port that is used for standard networking.[0/694]<br />
broadcastInterval=5 # Amount of time in seconds between two full network update broadcasts. Update broadcasts update all the content of a sector, not just what recently changed.<br />
isMultiplayer=true # Enable to allow multiplayer on this server. If disabled, only a single administrator can log in (ie. Singleplayer).<br />
isListed=false # Enable to list on public server lists.<br />
vacSecure=true # Enable to do VAC checks on users. Can only be active when using Steam networking.<br />
sendStatsToAdmins=true # Enable to send performance stats to logged in administrators. May use a lot of traffic.<br />
useSteam=true # Enable to use Steam networking. Highly recommended for public servers.<br />
forceSteam=false # Enable to force usage of Steam networking. Server won't fall back to TCP protocols and will die on startup if something goes wrong while connecting.<br />
rconIp= # The RCON interface IP that the server uses.<br />
rconPassword= # The RCON interface password of the server. Without password, RCON is disabled.<br />
rconPort=27015 # The RCON interface port that the server uses.<br />
maxReceivableMessageSize=52428800 # Maximum receivable message size in bytes that the server will accept. Any message that is larger than this will be silently discarded. Note: Default setting should be plenty enough.<br />
networkingThreads=2 # Number of threads that will be doing message receiving, processing and sending. Minimum amount is 2.<br />
[Administration]<br />
maxPlayers=10 # Maximum amount of players that are allowed on the server. In addition, one extra administrator is allowed. Please note that Avorion is NOT AN MMO and just because you can configure more players for your server, it's not always a good idea to do so!<br />
name=Avorion Server # Name of the server as it will show up in server lists.<br />
description=An Avorion Server # Description of the server as it will show up in server lists.<br />
password= # Password required for users that log in. Leave empty for no password.<br />
pausable=false # Enable to make the server pausable. Public servers can only be paused if the user may execute the /pause command, and only 1 or fewer users are online.<br />
accessListMode=Blacklist # Use 'whitelist' or 'blacklist' to enable blacklisting or whitelisting of users. Black/Whitelist files can be found in the galaxy folder.<br />
steamIdOverride=0 # Enter a SteamID (number) here to log in as that player. Should only be used for finding errors. When logging in 2 or more players while this setting is enabled, the behavior is undefined.<br />
[Meta]<br />
branch= # Only used in Singleplayer, to identify the last played branch. Will be ignored completely. You can ignore this, too.</pre><br />
<br />
<center>[[My Avorion Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Avorion_Info&diff=3048My Avorion Info2023-09-02T21:57:14Z<p>Paul: </p>
<hr />
<div>== Avorion headless server ==<br />
<br />
These steps were created using Ubuntu 20.04.6 LTS and Avorion server 2.3.1.<br />
<br />
Steps<br />
# Ensure that SteamCMD is installed. The steps to install are [https://developer.valvesoftware.com/wiki/SteamCMD here].<br />
# Create a directory for Avorion headless server application.<br />
# Create a directory for Avorion galaxy files.<br />
# Install Avorion headless server application.<br />
# Start, Save, and Stop Avorion headless server application.<br />
# Update Avorion headless server application.<br />
<br />
For all the steps use your Steam user created for steamcmd. My user is called 'steamy' and the command used to switch to user steamy is:<br />
<br />
<code>$ sudo -u steamy -s</code><br />
<br />
=== Installing Avorion via steamcmd ===<br />
<br />
'''Ensure steamcmd is installed.'''<br />
<br />
=== Create directory for Avorion headless server application ===<br />
<br />
I created a directory called Avorion in the user steamy home directory. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion</code><br />
<br />
=== Create a directory for Avorion galaxy files ===<br />
<br />
I created a directory called Avorion_Galaxies in the user steamy home directory for Avorion headless server app galaxies. Command used:<br />
<br />
<code>mkdir /home/steamy/Avorion_Galaxies</code><br />
<br />
=== Install Avorion headless server application ===<br />
<br />
Command format:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir <SERVER_PATH> +app_update 565060 validate +exit</code><br />
<br />
The SERVER_PATH is the absolute path to Avorion headless server application files. The SERVER_PATH for my steps is /home/steamy/Avorion. Command used:<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
Result:<br />
<br />
<pre>steamy@steamnuc00:~$ steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit<br />
Redirecting stderr to '/home/steamy/.steam/logs/stderr.txt'<br />
[ 0%] Checking for available updates...<br />
[----] Verifying installation...<br />
Steam Console Client (c) Valve Corporation - version 1691628584<br />
-- type 'quit' to exit --<br />
Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory<br />
OK<br />
<br />
Connecting anonymously to Steam Public...OK<br />
Waiting for client config...OK<br />
Waiting for user info...OK<br />
Please use force_install_dir before logon!<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)<br />
Update state (0x61) downloading, progress: 4.61 (6291456 / 136420041)<br />
Update state (0x61) downloading, progress: 27.83 (37970732 / 136420041)<br />
Update state (0x61) downloading, progress: 50.12 (68379436 / 136420041)<br />
Update state (0x61) downloading, progress: 70.63 (96351157 / 136420041)<br />
Update state (0x61) downloading, progress: 93.85 (128031433 / 136420041)<br />
Success! App '565060' fully installed.<br />
CWorkThreadPool::~CWorkThreadPool: work processing queue not empty: 1 items discarded.<br />
steamy@steamnuc00:~$</pre><br />
<br />
=== Start, Save, and Stop Avorion headless server application ===<br />
<br />
Command:<br />
<br />
<code>./server.sh --galaxy-name <GALAXY_NAME> --admin <64-bit SteamID> --datapath <GALAXY_PATH></code><br />
<br />
GALAXY_NAME is the name of your galaxy. For this setup, I used <code>Andromedia</code>. <span style="color:red">NOTE: If the GALAXY_NAME doesn't exist, this command will create a galaxy with the GALAXY_NAME value.</span><br />
64-bit SteamID is your 64-bit SteamID. For this setup, use your own 64-bit SteamID.<br />
GALAXY_PATH is the directory where you will store your galaxies. I used <code>/home/steamy/Avorion_Galaxies/</code>.<br />
<br />
Command used without my SteamID:<br />
<br />
<code>./server.sh --galaxy-name Andromeda --admin <64-bit SteamID> --datapath /home/steamy/Avorion_Galaxies/</code><br />
<br />
Once your Avorion headless server application is running, type <code>/save</code> to save galaxy or <code>/stop</code> to exit application. <span style="color:blue">It is good practice to always use /save and then /stop.</span><br />
<br />
<span style="color:red">NOTE: Always stop the server by using <code>/stop</code> command. Closing the console window may cause issues with your galaxy or Avorion headless server application files.</span><br />
<br />
=== Configure Avorion headless server galaxy ===<br />
<br />
[[Avorion server.ini README contents]]<br />
<br />
Make any changes to your server.ini you need by editing the server.ini of your galaxy. It is stored at <GALAXY_PATH>/<GALAXY_NAME>. Save the file after making any changes.<br />
<br />
Suggest making a backup of server.ini before making changes!<br />
<br />
=== Update Avorion headless server application ===<br />
<br />
To update your Avorion headless server application, run the same command used to install the application.<br />
<br />
<code>steamcmd +login anonymous +force_install_dir /home/steamy/Avorion +app_update 565060 validate +exit</code><br />
<br />
== Avorion game info ==<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Avorion_Info&diff=3047My Avorion Info2023-09-02T17:30:49Z<p>Paul: initial page creation</p>
<hr />
<div>== Avorion headless server ==<br />
<br />
Steps were created using Ubuntu 20.04.6 LTS.<br />
<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Gaming&diff=3046Gaming2023-09-02T17:28:01Z<p>Paul: /* Avorion */</p>
<hr />
<div>== Avorion ==<br />
<br />
[[My Avorion Info]]<br />
<br />
== Factorio ==<br />
<br />
[[My Factorio Info]]<br />
<br />
== Minecraft ==<br />
[[Minecraft]]<br />
<br />
== Software distribution systems ==<br />
<br />
Steam<br />
<br />
Impulse<br />
<br />
Good Old Games<br />
<br />
<center>[[Hobbies|To Hobbies]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Gaming&diff=3045Gaming2023-09-02T17:27:47Z<p>Paul: /* Factorio */</p>
<hr />
<div>== Avorion ==<br />
<br />
== Factorio ==<br />
<br />
[[My Factorio Info]]<br />
<br />
== Minecraft ==<br />
[[Minecraft]]<br />
<br />
== Software distribution systems ==<br />
<br />
Steam<br />
<br />
Impulse<br />
<br />
Good Old Games<br />
<br />
<center>[[Hobbies|To Hobbies]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_Factorio_Info&diff=3044My Factorio Info2023-09-02T17:27:16Z<p>Paul: initial page creation</p>
<hr />
<div>== Factorio Headless Setup ==<br />
<br />
Resources:<br />
* [https://wiki.factorio.com/Multiplayer Multiplayer Factorio wiki]<br />
* Stable [https://factorio.com/get-download/stable/headless/linux64 Factorio headless] server<br />
<br />
Check that your version of glibc is >= 2.18.<br />
<br />
<pre>robot01@apu01:~$ ldd --version<br />
ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23<br />
Copyright (C) 2016 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
Written by Roland McGrath and Ulrich Drepper.</pre><br />
<br />
Output of ldd command confirms glibc version 2.23.<br />
<br />
Switch to <code>/opt</code> directory and download latest Factorio stable headless version (0.16.36 as of this writing)<br />
<pre>robot01@apu01:~$ cd /opt<br />
robot01@apu01:/opt$ sudo wget https://factorio.com/get-download/stable/headless/linux64<br />
...<br />
...<br />
...<br />
Saving to: ‘linux64’<br />
<br />
linux64 100%[==========================================================>] 54.53M 52.4MB/s in 1.0s <br />
<br />
2022-04-09 09:36:49 (52.4 MB/s) - ‘linux64’ saved [57178436/57178436]</pre><br />
<br />
Rename file to match version (1.1.57 in this example)<br />
<pre>robot01@apu01:/opt$ sudo mv linux64 factorio_headless_x64_1.1.57.tar.xz</pre><br />
<br />
Extract archived and zipped file<br />
<pre>robot01@apu01:/opt$ sudo tar -xJf factorio_headless_x64_1.1.57.tar.xz<br />
robot01@apu01:/opt$ ls -l<br />
total 55844<br />
drwxr-xr-x 8 steamy steamy 4096 Apr 9 09:38 factorio<br />
-rw-r--r-- 1 root root 57178436 Mar 29 08:42 factorio_headless_x64_1.1.57.tar.xz</pre><br />
<br />
Remove file (save space, you can always download again if needed)<br />
<pre>robot01@apu01:/opt$ sudo rm factorio_headless_x64_1.1.57.tar.xz</pre><br />
<br />
Add a new user to run factorio and assign ownership of <code>/opt/factorio</code> directory to same user<br />
<pre>robot01@apu01:/opt$ sudo useradd factorio<br />
robot01@apu01:/opt$ sudo chown -R factorio:factorio /opt/factorio/</pre><br />
<br />
<br />
Verify permissions show factorio for both user and group<br />
<pre>robot01@apu01:/opt$ ls -l<br />
total 4<br />
drwxr-xr-x 4 factorio factorio 4096 May 1 21:12 factorio</pre><br />
<br />
<br />
Test Factorio binary by switching to factorio user then start server<br />
<pre>robot01@apu01:/opt$ sudo su - factorio<br />
No directory, logging in with HOME=/<br />
$</pre><br />
<br />
Start server and look for something like "File /savename does not exist."<br />
<pre>$ /opt/factorio/bin/x64/factorio --start-server savename<br />
0.000 2018-05-01 21:20:47; Factorio 0.16.36 (build 36253, linux64, headless)<br />
0.260 Operating system: Linux (Ubuntu 16.04)<br />
0.260 Program arguments: "/opt/factorio/bin/x64/factorio" "--start-server" "savename"<br />
0.260 Read data path: /opt/factorio/data<br />
0.260 Write data path: /opt/factorio [103696/111098MB]<br />
0.260 Binaries path: /opt/factorio/bin<br />
0.304 System info: [CPU: AMD G-T40E Processor, 2 cores, RAM: 3550 MB]<br />
0.304 Environment: DISPLAY=<unset>, WAYLAND_DISPLAY=<unset><br />
0.305 Running in headless mode<br />
0.316 Error GlobalModSettings.cpp:107: Failed to migrate mod settings file: Error when opening /opt/factorio/mods/mod-settings.json for reading: No such file or directory<br />
0.322 Loading mod core 0.0.0 (data.lua)<br />
0.388 Loading mod base 0.16.36 (data.lua)<br />
1.063 Loading mod base 0.16.36 (data-updates.lua)<br />
1.313 Checksum for core: 1316978547<br />
1.313 Checksum of base: 4140083139<br />
2.006 Info PlayerData.cpp:67: Local player-data.json unavailable<br />
2.006 Info PlayerData.cpp:72: Cloud player-data.json unavailable<br />
2.012 Custom inputs active: 0<br />
2.015 Factorio initialised<br />
2.016 Info ServerSynchronizer.cpp:29: nextHeartbeatSequenceNumber(0) initialized Synchronizer nextTickClosureTick(0).<br />
2.016 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(Ready) to(PreparedToHostGame)<br />
2.016 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(PreparedToHostGame) to(CreatingGame)<br />
2.017 Loading map /savename<br />
2.017 Error ServerMultiplayerManager.cpp:96: MultiplayerManager failed: "File /savename does not exist."<br />
2.017 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(CreatingGame) to(InitializationFailed)<br />
2.017 Info GlobalContext.cpp:694: Waiting for child processes to exit:<br />
2.020 Info ServerMultiplayerManager.cpp:142: Quitting multiplayer connection.<br />
2.020 Info ServerMultiplayerManager.cpp:698: mapTick(4294967295) changing state from(InitializationFailed) to(Closed)<br />
2.062 Info UDPSocket.cpp:206: Closing socket<br />
2.065 Goodbye</pre><br />
<br />
As factorio user create <code>/opt/factorio/</code> saves directory<br />
<pre>$ mkdir /opt/factorio/saves</pre><br />
<br />
At this point you can load up saved games or create some games. Before that I want to install Factorio init script<br />
<br />
Exit from factorio user back to sudo account<br />
<pre>$ exit<br />
logout</pre><br />
<br />
Switch to <code>/opt</code> directory<br />
<pre>robot01@apu01:/opt/factorio$ cd /opt</pre><br />
<br />
Clone Factorio init script from github<br />
<pre>robot01@apu01:/opt$ sudo git clone https://github.com/Bisa/factorio-init.git<br />
Cloning into 'factorio-init'...<br />
remote: Counting objects: 484, done.<br />
remote: Total 484 (delta 0), reused 0 (delta 0), pack-reused 484<br />
Receiving objects: 100% (484/484), 109.47 KiB | 0 bytes/s, done.<br />
Resolving deltas: 100% (276/276), done.<br />
Checking connectivity... done.</pre><br />
<br />
Make Factorio start on operating system boot and restart if failure (configurable - I kept defaults for now)<br />
<pre>robot01@apu01:/opt$ sudo cp /opt/factorio-init/factorio.service.example /etc/systemd/system/factorio.service<br />
robot01@apu01:/opt$ sudo systemctl daemon-reload</pre><br />
<br />
Sysvinit<br />
<pre>robot01@apu01:/opt/factorio$ sudo ln -s /opt/factorio-init/factorio /etc/init.d/factorio<br />
robot01@apu01:/opt/factorio$ sudo chmod +x /opt/factorio-init/factorio</pre><br />
<br />
Show help<br />
<pre>robot01@apu01:/opt/factorio$ service factorio help<br />
Usage: /etc/init.d/factorio COMMAND<br />
<br />
Available commands:<br />
start Starts the server<br />
stop Stops the server<br />
restart Restarts the server<br />
status Displays server status<br />
players-online Shows online players<br />
players Shows all players<br />
cmd [command/message] Open interactive commandline or send a single command to the server<br />
chatlog [--tail|-t] Print the current chatlog, optionally tail the log to follow in real time<br />
new-game name [map-gen-settings] [map-settings] Stops the server and creates a new game with the specified name using the specified map gen settings and map settings json files<br />
save-game name Stops the server and saves game to specified save<br />
load-save name Stops the server and loads the specified save<br />
install [tarball] Installs the server with optional specified tarball (omit to download and use the latest headless server from Wube)<br />
update [--dry-run] Updates the server<br />
invocation Outputs the invocation for debugging purpose<br />
listcommands List all init-commands<br />
listsaves List all saves<br />
version Prints the binary version<br />
help Shows this help message</pre><br />
<br />
Setup Autocompletion<br />
<pre>robot01@apu01:/opt/factorio$ sudo ln -s /opt/factorio-init/bash_autocomplete /etc/bash_completion.d/factorio<br />
robot01@apu01:/opt/factorio$ sudo echo "source /opt/factorio-init/bash_autocomplete" >> ~/.bashrc</pre><br />
<br />
Copy example server settings (make any changes you want to copy)<br />
<pre>robot01@apu01:/opt/factorio$ sudo cp /opt/factorio/data/server-settings.example.json /opt/factorio/data/server-settings.json</pre><br />
<br />
Copy example configuration (make any changes you want to copy)<br />
<pre>robot01@apu01:/opt/factorio$ sudo cp /opt/factorio-init/config.example /opt/factorio-init/config</pre><br />
<br />
Make any changes to config ini<br />
<pre>robot01@apu01:/opt/factorio$ sudo vi /opt/factorio/config/config.ini</pre><br />
<br />
=== Update headless server ===<br />
<br />
download latest headless version<br />
<br />
unzip and untar<br />
<br />
<pre>sudo tar -xJf linux64</pre><br />
<br />
change permissions to your dedicated factorio user<br />
<br />
<pre>sudo chown -R steamy:steamy factorio</pre><br />
<br />
launch game<br />
<br />
[[Gaming]]</div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Ubuntu&diff=3043Ubuntu2023-09-02T17:26:47Z<p>Paul: /* Factorio Headless Setup */</p>
<hr />
<div>== Shell commands ==<br />
<br />
Enable root account (not recommended):<br />
<pre>$sudo passwd root</pre><br />
<br />
Disable root account you lock root account:<br />
<pre>$sudo passwd -l root</pre><br />
<br />
Want to use root @ console:<br />
<pre>$sudo -i</pre><br />
<br />
[https://help.ubuntu.com/community/WindowsDualBoot Windows Dual Boot] page<br />
<br />
[https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows Recovering Ubuntu After Windows Install]<br />
<br />
[https://wiki.ubuntu.com/Grub2 Grub2] on Ubuntu wiki<br />
<br />
[http://www.howtogeek.com/howto/43471/how-to-configure-the-linux-grub2-boot-menu-the-easy-way/ Grub2 GUI] Customizer<br />
<br />
For support-related question you can use [https://answers.launchpad.net/ Launchpad]. You can also search the complete history of questions and answers.<br />
<br />
[http://ubuntuforums.org/ Ubuntu web forums]<br />
<br />
[http://ubuntuforums.org/showthread.php?t=1195275 Grub 2] basics<br />
<br />
=== Enable SSH server ===<br />
<br />
<code>apt-get install openssh-server</code><br />
<br />
[https://coderwall.com/p/yz-2_a/limit-ssh-access-by-ip-address Secure SSH server using /etc/hosts.allow]<br />
<br />
=== Add a User ===<br />
<br />
Example adding a user with username johndoe. Follow the instructions provided by the command.<br />
<br />
<code>sudo adduser johndoe</code><br />
<br />
=== Networking utilities ===<br />
<br />
See IP address information<br />
<br />
<code>ip a</code><br />
<br />
==== Configure hostname ====<br />
<br />
[https://linuxize.com/post/how-to-change-hostname-on-ubuntu-18-04/ How to change hostname on Ubuntu 18 04]<br />
<br />
==== systemctl ====<br />
<br />
Verify which processes run on Ubuntu 18.04 start up use <code>$ sudo systemctl list-unit-files</code>.<br />
<br />
=== Check version of Ubuntu ===<br />
<code>$ cat /etc/os-release</code><br />
<br />
== CLI Software Management ==<br />
<br />
Synchronize package index from Internet. Location of repositories <code>/etc/apt/sources.list</code><br />
<pre>sudo apt-get update</pre><br />
Install newest versions of all software packages<br />
<pre>sudo apt-get upgrade</pre><br />
Update distribution<br />
<pre>sudo apt-get dist-upgrade</pre><br />
Install package (if already installed, will attempt to update package)<br />
<pre>apt-get install package-name</pre><br />
List installed packages<br />
<pre>apt list --installed</pre><br />
<br />
List installed packages that start with 'python'<br />
<pre>$ apt list -a --installed python*</pre><br />
<br />
== Python on Ubuntu Notes ==<br />
<br />
See [[ Python | My Python Notes]] for information not specific to Ubuntu and Python.<br />
<br />
Verify Python 3 is installed<br />
<pre>anon@hammerhead:~$ python --version<br />
<br />
Command 'python' not found, but can be installed with:<br />
<br />
sudo apt install python3 <br />
sudo apt install python <br />
sudo apt install python-minimal<br />
<br />
You also have python3 installed, you can run 'python3' instead.<br />
<br />
anon@hammerhead:~$ python3 --version <----- Python 3 installed.<br />
Python 3.6.7 <----- Version 3.6.7</pre><br />
<br />
Verify Python 3 PIP installed<br />
<pre>$ pip3 --version<br />
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)</pre><br />
<br />
To install Python 3 PIP<br />
<pre>$ sudo apt-get install -y python3-pip</pre><br />
<br />
I use Python virtual environments. Verify Python venv module is installed<br />
<pre>$ apt list -a --installed *venv* <----- If nothing with Python 3 venv comes back then you most install venv module</pre><br />
<br />
To install Python 3 venv module<br />
<pre>$ sudo apt-get install -y python3-venv</pre><br />
<br />
Create virtual environment. I keep my Python virtual environments in a single directory. To create directory <code>$ mkdir python-venv</code><br />
<br />
Switch do directory <code>$ cd python-venv/</code><br />
<br />
Create virtual environment<br />
<pre>$ python3 -m venv udmey-django</pre><br />
<br />
Activate virtual environment<br />
<pre>$ source udmey-django/bin/activate</pre><br />
<br />
Prompt changes to reflect virtual environment<br />
<pre>(udmey-django) anon@hammerhead:~/python-venv$</pre><br />
<br />
Note: Within virtual environment, you can use the command python instead of python3, and pip instead of pip3.<br />
<br />
Deactivate virtual environment and prompt returns to normal<br />
<pre>$ deactivate</pre><br />
<br />
== mongoDB ==<br />
<br />
[[My MongoDB notes]]<br />
<br />
== PostgreSQL ==<br />
<br />
=== Install PostgreSQL ===<br />
<br />
<pre>$ sudo apt install postgresql postgresql-contrib<br />
...<br />
Success. You can now start the database server using:<br />
<br />
/usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start<br />
<br />
Ver Cluster Port Status Owner Data directory Log file<br />
10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log<br />
update-alternatives: using /usr/share/postgresql/10/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode<br />
Setting up postgresql (10+190) ...<br />
Setting up postgresql-contrib (10+190) ...<br />
Processing triggers for systemd (237-3ubuntu10.11) ...<br />
Processing triggers for ureadahead (0.100.0-20) ...</pre><br />
<br />
=== Use PostgreSQL ===<br />
<br />
Switch to postgres account<br />
<pre>sudo -i postgres</pre><br />
Access PostgreSQL prompt<br />
<pre>psql</pre><br />
Exit PostgreSQL prompt<br />
<pre>\q</pre><br />
Log directly into PostgreSQL prompt with postgres user<br />
<pre>sudo -u postgres psql</pre><br />
Add user (username must be same as PostgreSQL role and database)<br />
<pre>sudo adduser user_name</pre><br />
Check current connection information<br />
<pre>\conninfo</pre><br />
<br />
<b>While logged in as postgres user...</b><br />
<br />
Create a new role. Use <code>man createuser</code> for more information.<br />
<pre>createuser --interactive</pre><br />
Create new database<br />
<pre>createdb db_name</pre><br />
Same user connect to different database<br />
<pre>psql -d postgres</pre><br />
<br />
== Nginx ==<br />
<br />
[[My Nginx notes]]<br />
<br />
[https://www.tecmint.com/install-nginx-with-virtual-hosts-and-ssl-certificate/ Install Nginx with virtual hosts and SSL certificates]<br />
<br />
== Apache 2 ==<br />
<br />
=== Resources ===<br />
<br />
[https://help.ubuntu.com/lts/serverguide/httpd.html Ubuntu server guide to HTTPD]<br />
<br />
[https://help.ubuntu.com/community/OpenSSL#SSL_Certificates Ubuntu Open SSL guide]<br />
<br />
[https://help.ubuntu.com/lts/serverguide/certificates-and-security.html.en Ubuntu Certificates and Security]<br />
<br />
[http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html SSL Certificate HOWTO] not Ubuntu specific<br />
<br />
[https://stuff-things.net/2015/09/28/configuring-apache-for-ssl-client-certificate-authentication/ Configure Apache for SSL client certificate authentication]<br />
<br />
=== Installation ===<br />
<br />
Update all your software and install Apache 2<br />
<br />
<pre># apt-get update<br />
# apt-get upgrade<br />
# apt install apache2</pre><br />
<br />
Verify Apache is running<br />
<pre># systemctl status apache2<br />
● apache2.service - The Apache HTTP Server<br />
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)<br />
Drop-In: /lib/systemd/system/apache2.service.d<br />
└─apache2-systemd.conf<br />
Active: active (running) since Sun 2018-10-21 14:44:30 CDT; 11min ago<br />
Main PID: 17131 (apache2)<br />
Tasks: 55 (limit: 4181)<br />
CGroup: /system.slice/apache2.service<br />
├─17131 /usr/sbin/apache2 -k start<br />
├─17132 /usr/sbin/apache2 -k start<br />
└─17134 /usr/sbin/apache2 -k start<br />
<br />
Oct 21 14:44:30 apu02 systemd[1]: Starting The Apache HTTP Server...<br />
Oct 21 14:44:30 apu02 apachectl[17120]: AH00558: apache2: Could not reliably determine the server's<br />
Oct 21 14:44:30 apu02 systemd[1]: Started The Apache HTTP Server.</pre><br />
<br />
=== Firewall ===<br />
<br />
Update firewall to allow only port 443 (default HTTPS TCP port)<br />
<br />
<pre># ufw app list<br />
Available applications:<br />
Apache<br />
Apache Full<br />
Apache Secure<br />
OpenSSH<br />
<br />
# ufw allow 'Apache Secure'<br />
<br />
# ufw status verbose | grep 443<br />
443/tcp (Apache Secure) ALLOW IN Anywhere<br />
443/tcp (Apache Secure (v6)) ALLOW IN Anywhere (v6)</pre><br />
<br />
== Teamspeak 3 setup on Ubuntu 16.04 and 18.x via command line ==<br />
Followed steps at [https://www.vultr.com/docs/how-to-install-teamspeak-3-server-on-ubuntu-16-04-64-bit How to install Teamspeak 3 server on Ubuntu 16.04 64-bit] to install Teamspeak 3 and get basic server running.<br />
<br />
If you want to customize the server port follow next steps.<br />
<br />
Install simple command-line program named [https://www.sqlite.org/cli.html sqlite3]. [https://www.sitepoint.com/getting-started-sqlite3-basic-commands/ How to use sqlite]<br />
<br />
<pre>robot00@apu00:~$ sudo apt install sqlite3</pre><br />
<br />
Launch sqlite3 using Teamspeak 3 sqlite database file:<br />
<br />
<pre>robot00@apu00:~$ sudo sqlite3 /home/teamspeak/ts3server.sqlitedb<br />
SQLite version 3.11.0 2016-02-15 17:29:24<br />
Enter ".help" for usage hints.</pre><br />
<br />
Update port command:<br />
<br />
<pre>sqlite> update servers set server_port=<CUSTOM UDP Port>;</pre><br />
<br />
Restart Teamspeak 3 server<br />
<br />
<pre>robot00@apu00:~$ systemctl restart teamspeak.service</pre><br />
<br />
Test your connection using the <CUSTOM UDP Port><br />
<br />
=== Upgrade Teamspeak3 server ===<br />
<br />
[https://www.gazblog.com/2019/01/update-teamspeak-3-server-on-ubuntu-18-04/ original steps]<br />
<br />
Login to SSH as root<br />
<br />
Stop your current Teamspeak 3 Server <code>systemctl stop teamspeak.service</code><br />
<br />
Change to your teamspeak user <code>cd /home/teamspeak/;su teamspeak</code><br />
<br />
Download Teamspeak, extract it, update and tidy up.<br />
<pre>wget https://files.teamspeak-services.com/releases/server/3.9.1/teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
tar xvfj teamspeak3-server_linux_amd64-3.9.1.tar.bz2<br />
cd teamspeak3-server_linux_amd64<br />
cp * -R /home/teamspeak<br />
cd ..<br />
rm -r teamspeak3-server_linux_amd64<br />
rm teamspeak3-server_linux_amd64-3.9.1.tar.bz2</pre><br />
<br />
Return to root and start the Teamspeak server<br />
<pre>exit<br />
systemctl start teamspeak.service<br />
</pre><br />
<br />
Check to make you can connect to Teamspeak 3 server<br />
<br />
== Factorio Headless Setup ==<br />
<br />
[[My Factorio Info]]<br />
<br />
== Hardware ==<br />
<br />
Identify video card:<br />
<pre>paul@congo:~$ lspci -nn | grep VGA<br />
01:00.0 VGA compatible controller [0300]: nVidia Corporation G92 [GeForce 8800 GT] [10de:0611] (rev a2)</pre><br />
<br />
Verify interface speed<br />
<br />
<code>cat /sys/class/net/<interface>/speed</code><br />
<br />
replace <interface> with name of your NIC (e.g. eth0)<br />
<br />
[[Ubuntu video card]]<br />
<br />
<center>[[Linux|To Linux]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Gaming&diff=3042Gaming2023-09-02T17:24:50Z<p>Paul: /* Minecraft */</p>
<hr />
<div>== Avorion ==<br />
<br />
== Factorio ==<br />
<br />
== Minecraft ==<br />
[[Minecraft]]<br />
<br />
== Software distribution systems ==<br />
<br />
Steam<br />
<br />
Impulse<br />
<br />
Good Old Games<br />
<br />
<center>[[Hobbies|To Hobbies]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=Minecraft&diff=3041Minecraft2023-09-01T14:36:56Z<p>Paul: /* Backing up your Minecraft world */</p>
<hr />
<div>== Minecraft server view-distance and lag notes ==<br />
<br />
If your processor, network connection, and RAM are sufficient then the bottle neck for performance is very likely server storage (hard drive or SSD) speed. You reduce server storage input/output (I/O) by reducing view-distance. View-distance determines how much of the Minecraft world a player sees (the fog in the distance is the cut off of view-distance). Raise view-distance and all players see farther (clients can reduce their view-distance in video options). Lower view-distange see closer. View-distance is used in the calculation of mob spawns, higher means increased mob numbers, lower produces less mob spawns. This section of information is about elimination of lag, skipping ticks, system time change, and server overload issues. Read on for more details.<br />
<br />
Minecraft software: '''Minecraft server jar version 1.8.9 Vanilla (no mods)'''<br />
<br />
Server operating system: Linux Fedora Core Release 23 64-bit<br />
<br />
Server hardware specs:<br />
* CPU: Intel Core i5-6600 6M Skylake Quad-Core 3.3 GHz<br />
* Mobo: SABERTOOTH Z170 MARK 1<br />
* RAM: 32GB (4x8GB) 288-Pin DDR4 SDRAM DDR4 2133 (PC4 17000)<br />
* Video: Built-in Intel<br />
* Drive: Samsung 950Pro SSD<br />
* PSU: Coolmaster GX 750W<br />
<br />
<br />
''The key to this setup is the very fast Samsung Pro 950 SSD (M.2 form factor using NVMe).''<br />
<br />
<br />
I've been hosting a private friends / family vanilla Minecraft server since 2010. The server routinely supports 8 to 10 simultaneous connected users. Users are connected via Gigabit LAN and Gigabit WAN (Google Fiber 1Gbps synchronous).<br />
<br />
<br />
The server jar file is launched with -Xmx1g -Xms1g arguments.<br />
<br />
<br />
Operating system: Fedora Core Release 23 (use Linux based OS as server storage I/O is superior than Windows based OS).<br />
<br />
<br />
After many hours of play testing / changing view-distance over the years with different server storage below are the settings that clients would experience zero lag.<br />
<br />
<br />
* The server originally had a 7200 RPM hard disk drive. '''''view-distance set to 6 to avoid lag issues.'''''<br />
* Switched to SATA connected SSD. '''''The view-distance set to 8 to avoid lag issues.'''''<br />
* Switched to M.2 form NVMe SSD (Samsung Pro950). '''''The view-distance set to 16. No lag issues.'''''<br />
<br />
<br />
Note that the above systems never had CPU or RAM issues.<br />
<br />
<br />
To take advantage of OS having faster storage I/O and Minecraft server software I upgraded to Z170 chipset that supports booting to M.2 form factor SSD using NVMe (the Samsung Pro 950 256GB). The Minecraft directories and files are on the same partition as the OS (previous versions I used separate drives for OS and Minecraft).<br />
<br />
<br />
I haven't tried a view-distance above 16 because everyone is really pleased with the results with one exception. The number of mob spawns is 2 to 3 times worse than before so nobody wants to have a higher view-distance for fear of even more mob spawning. Attacking pig man zombies with this hardware and software setup is very dangerous!<br />
<br />
== Windows Operating System ==<br />
<br />
My tips for running Minecraft on Windows machines.<br />
<br />
* Update video driver<br />
* Update Java software at [http://java.com Java] website<br />
* Allocate more memory only if you get "out of memory errors"<br />
<br />
=== Allocate More Memory to Minecraft ===<br />
<br />
Thought I'd share my success at memory allocation changes with those who are interested.<br />
<br />
'''Note:''' I only changed my memory allocations on my machine due to in-game memory crashes every 90 to 120 seconds when exploring outside. Once I allocated 768m I haven't had a memory crash. This memory allocation started happening to my machine since 1.7 beta.<br />
<br />
I was trying various configurations to allocate memory but my command window would open up then immediately close or Java Virtual Machine (JVM) would not launch, etc.<br />
<br />
I have Win7 Ultimate 64-bit, 12 GB RAM, with current version of Java installed.<br />
<br />
I created a batch file & updated my PATH variable with directory of current Java version.<br />
<br />
Batch file contains (use your own c:\path2minecraft.exe here):<br />
<pre>javaw -Xms768m -jar "c:\minecraft\Minecraft.exe"</pre><br />
<br />
Added this to PATH (don't forget the semi-colon to separate this path from previous one):<br />
<pre>;C:\Program Files (x86)\Java\jre7\bin</pre><br />
<br />
'''Add to PATH steps: For Win7 Ultimate I right click Computer > Properties > Advanced System Settings > Advanced Tab > Environmental Variables > System Variables > highlight PATH then click EDIT. Add semi-colon then PATH to current version of Java then press Okay.'''<br />
<br />
''Side Note: The same machine runs minecraft flawless in Fedora Core 15 & 16 without memory modifications. Only the lack of Ventrilo support on Linux causes me to use Windows to run minecraft.''<br />
<br />
I've read about other people starting minecraft.exe with -Xmx parameter but I could not get various options to work, even though I have 12 GB RAM.<br />
<br />
== Fedora Core Linux Operating System ==<br />
<br />
My tips for running Minecraft on Fedora Core 14, 15 & 16 systems.<br />
<br />
* Update video driver<br />
** I use NVidia video cards. See my Linux [[NVidia]] driver installation page<br />
* Update Java software at [http://java.com Java] website<br />
** Launch Java from command line by pointing to current version of Java (or update your PATH variable)<br />
** Example [client start]: <code>/usr/java/latest/bin/java -jar minecraft.jar</code><br />
** Example [server start]: <code>/usr/java/latest/bin/java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui</code><br />
'''Note: Above commands assume you are in same directory as minecraft .jar files, otherwise, specify path to .jar files'''<br />
<br />
== Ubuntu Operating System ==<br />
<br />
If you launch minecraft client and see an error message with ".minecraft/bin/natives/liblwjgl.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)" then follow these steps:<br />
<br />
=== Install Lightweight Java Game Library ===<br />
<br />
# Go to http://lwjgl.org/download.php<br />
# Click the link to download the newest stable release<br />
# Download lwjgl-x.x.x.zip (lwjgl-2.8.4.zip was latested on 8-21-2012)<br />
# In your home directory Ctrl + H to show hidden files<br />
# Go to .minecraft/bin directory and copy matching .jar files from the jar folder in the lwjgl directory. I copied jinput.jar, lwjgl.jar, and lwjgl_util.jar.<br />
# Go to .minecraft/bin/native directory and copy matching .so files from the native/linux folder in the lwjgl directory. I copied all six files libjinput-linux64.so, liblwjgl64.so, libopenal64.so, libjinput-linux.so, liblwjgl.so, and libopenal.so.<br />
<br />
Minecraft should now work correctly!<br />
<br />
== Linux Mint ==<br />
<br />
=== Mint 16 with KDE Desktop ===<br />
<br />
'''Setup current Oracle Java 64-bit (Java version 7 update 51 as of this writing):'''<br />
# [http://java.com/en/download/linux_manual.jsp?locale=en Download latest version of Linux x64]<br />
# Create directory you want to install Java. As root <code>mkdir /usr/java/</code><br />
# Change to directory <code>cd /usr/java</code><br />
# Move the jre-7u51-linux-x64.tar.gz file to the /usr/java directory.<br />
# Uncompress and unpack the tarball to install Java. <code>tar zxvf jre-7u51-linux-x64.tar.gz</code><br />
#* The Java files are installed in a directory called /usr/java/jre1.7.0_51/<br />
# Delete .tar.gz file <code>rm /usr/java/jre-7u9-linux-64.tar.gz</code><br />
<br />
'''Setup minecraft server:'''<br />
# Create minecraft directory. As root <code>mkdir /minecraft</code><br />
# Change ownership to user. As root <code>chown username:username /minecraft</code><br />
# Swith to username then download [http://minecraft.net/download minecraft_server.jar] to /minecraft directory<br />
# Launch minecraft server using Oracle's 64-bit Java: <code>/usr/java/jre1.7.0_51/bin/java -Xmx1024m -Xms1024M -jar minecraft_server.jar nogui</code><br />
# Type /help at Minecraft prompt to get a list of server commands.<br />
# I stop server here and customize the server.properties folder to what you want. Then restart server.<br />
<br />
'''After you setup your directories change the ownership of the directories and all files in /usr/java & /minecraft to non-privileged user.'''<br />
<br />
Example with user and group named "bigfoot".<br />
<pre>chown -R bigfoot:bigfoot /minecraft<br />
chown -R bigfoot:bigfoot /usr/java</pre><br />
<br />
'''Using the minecraft_server.jar in nogui mode does not require any changes to your video card drivers'''<br />
<br />
==== Example start up of first Minecraft server ====<br />
This example I used an existing server.properties file and simply changed the name of test world to "wildlands".<br />
<pre><br />
bigfoot@sweetcandy:/minecraft > /usr/java/jre1.7.0_51/bin/java -Xmx1024m -Xms1024M -jar minecraft_server.jar nogui<br />
[11:59:12] [Server thread/INFO]: Starting minecraft server version 1.7.4<br />
[11:59:12] [Server thread/INFO]: Loading properties<br />
[11:59:12] [Server thread/INFO]: Default game type: SURVIVAL<br />
[11:59:12] [Server thread/INFO]: Generating keypair<br />
[11:59:12] [Server thread/INFO]: Starting Minecraft server on *:25565<br />
[11:59:12] [Server thread/INFO]: Preparing level "wildlands"<br />
[11:59:13] [Server thread/INFO]: Preparing start region for level 0<br />
[11:59:14] [Server thread/INFO]: Preparing spawn area: 5%<br />
[11:59:15] [Server thread/INFO]: Preparing spawn area: 12%<br />
[11:59:16] [Server thread/INFO]: Preparing spawn area: 20%<br />
[11:59:17] [Server thread/INFO]: Preparing spawn area: 29%<br />
[11:59:18] [Server thread/INFO]: Preparing spawn area: 38%<br />
[11:59:19] [Server thread/INFO]: Preparing spawn area: 47%<br />
[11:59:20] [Server thread/INFO]: Preparing spawn area: 57%<br />
[11:59:21] [Server thread/INFO]: Preparing spawn area: 67%<br />
[11:59:22] [Server thread/INFO]: Preparing spawn area: 77%<br />
[11:59:23] [Server thread/INFO]: Preparing spawn area: 86%<br />
[11:59:24] [Server thread/INFO]: Preparing spawn area: 96%<br />
[11:59:24] [Server thread/INFO]: Done (12.118s)! For help, type "help" or "?"<br />
</pre><br />
Type "help or ?" at prompt to show commands<br />
<pre><br />
?<br />
[11:59:30] [Server thread/INFO]: --- Showing help page 1 of 7 (/help <page>) ---<br />
[11:59:30] [Server thread/INFO]: /achievement give <stat_name> [player]<br />
[11:59:30] [Server thread/INFO]: /ban <name> [reason ...]<br />
[11:59:30] [Server thread/INFO]: /ban-ip <address|name> [reason ...]<br />
[11:59:30] [Server thread/INFO]: /banlist [ips|players]<br />
[11:59:30] [Server thread/INFO]: /clear <player> [item] [data]<br />
[11:59:30] [Server thread/INFO]: /debug <start|stop><br />
[11:59:30] [Server thread/INFO]: /defaultgamemode <mode><br />
</pre><br />
I always issue "save-all" then "stop" command when taking server offline.<br />
<pre><br />
save-all<br />
[11:59:36] [Server thread/INFO]: Saving...<br />
[11:59:36] [Server thread/INFO]: Saved the world<br />
stop<br />
[11:59:38] [Server thread/INFO]: Stopping the server<br />
[11:59:38] [Server thread/INFO]: Stopping server<br />
[11:59:38] [Server thread/INFO]: Saving players<br />
[11:59:38] [Server thread/INFO]: Saving worlds<br />
[11:59:38] [Server thread/INFO]: Saving chunks for level 'wildlands'/Overworld<br />
[11:59:38] [Server thread/INFO]: Saving chunks for level 'wildlands'/Nether<br />
[11:59:38] [Server thread/INFO]: Saving chunks for level 'wildlands'/The End<br />
</pre><br />
<br />
=== MATE Desktop ===<br />
<br />
<br />
=== Cinnamon Desktop (with Mint 14 & 15) ===<br />
<br />
'''Setup current Oracle Java 64-bit (Java version 7 update 9 as of this writing):'''<br />
# [http://java.com/en/download/linux_manual.jsp?locale=en Download latest version of Linux x64]<br />
# Create directory you want to install Java. As root <code>mkdir /usr/java/</code><br />
# Change to directory <code>cd /usr/java</code><br />
# Move the jre-7u9-linux-64.tar.gz file to the /usr/java directory.<br />
# Uncompress and unpack the tarball to install Java. <code>tar zxvf jre-7u9-linux-x64.tar.gz</code><br />
#* The Java files are installed in a directory called /usr/java/jre1.7.0_09/<br />
# Delete .tar.gz file <code>rm /usr/java/jre-7u51-linux-x64.tar.gz</code><br />
<br />
'''Setup minecraft server:'''<br />
# Create minecraft directory. As root <code>mkdir /minecraft</code><br />
# Change ownership to user. As root <code>chown username:username /minecraft</code><br />
# Swith to username then download [http://minecraft.net/download minecraft_server.jar] to /minecraft directory<br />
# Launch minecraft server using Oracle's 64-bit Java: <code>/usr/java/jre1.7.0_09/bin/java -Xmx1024m -Xms1024M -jar minecraft_server.jar nogui</code><br />
# Type /help at Minecraft prompt to get a list of server commands.<br />
# I stop server here and customize the server.properties folder to what you want. Then restart server.<br />
<br />
'''Using the minecraft_server.jar in nogui mode does not require any changes to your video card drivers'''<br />
<br />
Example of successful start:<pre>/minecraft $ /usr/java/jre1.7.0_09/bin/java -Xmx1024m -Xms1024M -jar minecraft_server.jar nogui<br />
208 recipes<br />
27 achievements<br />
2012-12-01 13:16:34 [INFO] Starting minecraft server version 1.4.5<br />
2012-12-01 13:16:34 [INFO] Loading properties<br />
2012-12-01 13:16:34 [INFO] Default game type: SURVIVAL<br />
2012-12-01 13:16:34 [INFO] Generating keypair<br />
2012-12-01 13:16:35 [INFO] Starting Minecraft server on *:25565<br />
2012-12-01 13:16:35 [INFO] Preparing level "hillville"<br />
2012-12-01 13:16:35 [INFO] Preparing start region for level 0<br />
2012-12-01 13:16:36 [INFO] Preparing spawn area: 54%<br />
2012-12-01 13:16:36 [INFO] Done (1.499s)! For help, type "help" or "?"</pre><br />
<br />
=== CentOS setup on CloudAtCost ===<br />
<br />
'''Install screen (if not already)'''<br />
<pre><br />
# yum install screen<br />
</pre><br />
<br />
'''Add a user'''<br />
<pre><br />
useradd -c "Minecraft user" -m mineuser<br />
</pre><br />
<br />
'''Create script'''<br />
<br />
Create file in /etc/init.d/ directory called minecraft and copy and paste the below script.<br />
<br />
<pre> <br />
#!/bin/bash<br />
# /etc/init.d/minecraft<br />
# version 0.3.9 2012-08-13 (YYYY-MM-DD)<br />
<br />
### BEGIN INIT INFO<br />
# Provides: minecraft<br />
# Required-Start: $local_fs $remote_fs screen-cleanup<br />
# Required-Stop: $local_fs $remote_fs<br />
# Should-Start: $network<br />
# Should-Stop: $network<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop: 0 1 6<br />
# Short-Description: Minecraft server<br />
# Description: Starts the minecraft server<br />
### END INIT INFO<br />
<br />
#Settings<br />
SERVICE='minecraft_server.jar'<br />
OPTIONS='nogui'<br />
USERNAME='mineuser'<br />
WORLD='world'<br />
MCPATH='/home/mineuser/minecraft'<br />
BACKUPPATH='/home/minecraft/backup/minecraft.backup'<br />
MAXHEAP=2048<br />
MINHEAP=2048<br />
HISTORY=1024<br />
CPU_COUNT=1<br />
INVOCATION="java -Xmx${MAXHEAP}M -Xms${MINHEAP}M -XX:+UseConcMarkSweepGC \<br />
-XX:+CMSIncrementalPacing -XX:ParallelGCThreads=$CPU_COUNT -XX:+AggressiveOpts \<br />
-jar $SERVICE $OPTIONS" <br />
<br />
ME=`whoami`<br />
as_user() {<br />
if [ $ME == $USERNAME ] ; then<br />
bash -c "$1"<br />
else<br />
su - $USERNAME -c "$1"<br />
fi<br />
}<br />
<br />
mc_start() {<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "$SERVICE is already running!"<br />
else<br />
echo "Starting $SERVICE..."<br />
cd $MCPATH<br />
as_user "cd $MCPATH && screen -h $HISTORY -dmS minecraft $INVOCATION"<br />
sleep 7<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "$SERVICE is now running."<br />
else<br />
echo "Error! Could not start $SERVICE!"<br />
fi<br />
fi<br />
}<br />
<br />
mc_saveoff() {<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "$SERVICE is running... suspending saves"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"say SERVER BACKUP STARTING. Server going readonly...\"\015'"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"save-off\"\015'"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"save-all\"\015'"<br />
sync<br />
sleep 10<br />
else<br />
echo "$SERVICE is not running. Not suspending saves."<br />
fi<br />
}<br />
<br />
mc_saveon() {<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "$SERVICE is running... re-enabling saves"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"save-on\"\015'"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"say SERVER BACKUP ENDED. Server going read-write...\"\015'"<br />
else<br />
echo "$SERVICE is not running. Not resuming saves."<br />
fi<br />
}<br />
<br />
mc_stop() {<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "Stopping $SERVICE"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"say SERVER SHUTTING DOWN IN 10 SECONDS. Saving map...\"\015'"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"save-all\"\015'"<br />
sleep 10<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"stop\"\015'"<br />
sleep 7<br />
else<br />
echo "$SERVICE was not running."<br />
fi<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "Error! $SERVICE could not be stopped."<br />
else<br />
echo "$SERVICE is stopped."<br />
fi<br />
} <br />
<br />
mc_update() {<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "$SERVICE is running! Will not start update."<br />
else<br />
as_user "cd $MCPATH && wget -q -O $MCPATH/versions http://s3.amazonaws.com/Minecraft.Download/versions/versions.json"<br />
snap=`awk -v linenum=3 'NR == linenum {print; exit}' "$MCPATH/versions"`<br />
snapVersion=`echo $snap | awk -F'\"' '{print $4}'`<br />
re=`awk -v linenum=4 'NR == linenum {print; exit}' "$MCPATH/versions"`<br />
reVersion=`echo $re | awk -F'\"' '{print $4}'`<br />
as_user "rm $MCPATH/versions"<br />
if [ "$1" == "snapshot" ]; then<br />
MC_SERVER_URL=http://s3.amazonaws.com/Minecraft.Download/versions/$snapVersion/minecraft_server.$snapVersion.jar<br />
else<br />
MC_SERVER_URL=http://s3.amazonaws.com/Minecraft.Download/versions/$reVersion/minecraft_server.$reVersion.jar<br />
fi<br />
as_user "cd $MCPATH && wget -q -O $MCPATH/minecraft_server.jar.update $MC_SERVER_URL"<br />
if [ -f $MCPATH/minecraft_server.jar.update ]<br />
then<br />
if `diff $MCPATH/$SERVICE $MCPATH/minecraft_server.jar.update >/dev/null`<br />
then <br />
echo "You are already running the latest version of $SERVICE."<br />
else<br />
as_user "mv $MCPATH/minecraft_server.jar.update $MCPATH/$SERVICE"<br />
echo "Minecraft successfully updated."<br />
fi<br />
else<br />
echo "Minecraft update could not be downloaded."<br />
fi<br />
fi<br />
}<br />
<br />
mc_backup() {<br />
mc_saveoff<br />
<br />
NOW=`date "+%Y-%m-%d_%Hh%M"`<br />
BACKUP_FILE="$BACKUPPATH/${WORLD}_${NOW}.tar"<br />
echo "Backing up minecraft world..."<br />
#as_user "cd $MCPATH && cp -r $WORLD $BACKUPPATH/${WORLD}_`date "+%Y.%m.%d_%H.%M"`"<br />
as_user "tar -C \"$MCPATH\" -cf \"$BACKUP_FILE\" $WORLD"<br />
<br />
echo "Backing up $SERVICE"<br />
as_user "tar -C \"$MCPATH\" -rf \"$BACKUP_FILE\" $SERVICE"<br />
#as_user "cp \"$MCPATH/$SERVICE\" \"$BACKUPPATH/minecraft_server_${NOW}.jar\""<br />
<br />
mc_saveon<br />
<br />
echo "Compressing backup..."<br />
as_user "gzip -f \"$BACKUP_FILE\""<br />
echo "Done."<br />
}<br />
<br />
mc_command() {<br />
command="$1";<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
pre_log_len=`wc -l "$MCPATH/logs/latest.log" | awk '{print $1}'`<br />
echo "$SERVICE is running... executing command"<br />
as_user "screen -p 0 -S minecraft -X eval 'stuff \"$command\"\015'"<br />
sleep .1 # assumes that the command will run and print to the log file in less than .1 seconds<br />
# print output<br />
tail -n $[`wc -l "$MCPATH/logs/latest.log" | awk '{print $1}'`-$pre_log_len] "$MCPATH/logs/latest.log"<br />
fi<br />
}<br />
<br />
#Start-Stop here<br />
case "$1" in<br />
start)<br />
mc_start<br />
;;<br />
stop)<br />
mc_stop<br />
;;<br />
restart)<br />
mc_stop<br />
mc_start<br />
;;<br />
update)<br />
mc_stop<br />
mc_backup<br />
mc_update $2<br />
mc_start<br />
;;<br />
backup)<br />
mc_backup<br />
;;<br />
status)<br />
if pgrep -u $USERNAME -f $SERVICE > /dev/null<br />
then<br />
echo "$SERVICE is running."<br />
else<br />
echo "$SERVICE is not running."<br />
fi<br />
;;<br />
command)<br />
if [ $# -gt 1 ]; then<br />
shift<br />
mc_command "$*"<br />
else<br />
echo "Must specify server command (try 'help'?)"<br />
fi<br />
;;<br />
<br />
*)<br />
echo "Usage: $0 {start|stop|update|backup|status|restart|command \"server command\"}"<br />
exit 1<br />
;;<br />
esac<br />
<br />
exit 0<br />
</pre><br />
<br />
'''Change variables in script to your values!'''<br />
<br />
Change the USERNAME, WORLD, MCPATH, BACKUPPATH, MAXHEAP, and MINHEAP to the values you want to use. MAXHEAP and MINHEAP I make the same value and represent the amount of memory you want to allocate to Minecraft server.<br />
<br />
'''Change permissions on the script'''<br />
<br />
<code># chmod a+x /etc/init.d/minecraft</code><br />
<br />
'''Add script to chkconfig'''<br />
<br />
<code># chkconfig --add minecraft</code><br />
<br />
'''Switch to Minecraft user and setup minecraft directory'''<br />
<br />
<code># su - mineuser</code><br />
<br />
<code>$ mkdir minecraft</code><br />
<br />
'''Change to directory:'''<br />
<br />
<code>$ cd minecraft</code><br />
<br />
'''Download the minecraft server file (this link is for 1.8 version):'''<br />
<br />
<pre>$ wget https://s3.amazonaws.com/Minecraft.Download/versions/1.8/minecraft_server.1.8.jar</pre><br />
<br />
'''Rename the minecraft server file:'''<br />
<br />
<code>$ mv minecraft_server.1.8.jar minecraft_server.jar</code><br />
<br />
''Note: The SERVICE='minecraft_server.jar' setting in script must match the name of the minecraft server file. I prefer to use generic name of minecraft_server.jar so when you upgrade from server version 1.y to 1.x you do not need to change any other scripts or configurations.''<br />
<br />
'''Use service command to start and stop minecraft'''<br />
<br />
<code>service minecraft (start | stop)</code><br />
<br />
'''To use screen'''<br />
<br />
View screen:<br />
<br />
<code>screen -r</code><br />
<br />
Exit screen:<br />
<br />
<code>CTRL+a+d</code><br />
<br />
'''Start minecraft'''<br />
<pre><br />
[mineuser@localhost ~]$ service minecraft start<br />
Starting minecraft_server.jar...<br />
minecraft_server.jar is now running.<br />
[mineuser@localhost ~]$ screen -r<br />
<br />
[16:27:24] [Server thread/INFO]: Starting minecraft server version 1.8<br />
[16:27:24] [Server thread/WARN]: To start the server with more ram, launch it as "java -Xmx1024M -Xms1024M -jar minecraft_server.jar"<br />
[16:27:24] [Server thread/INFO]: Loading properties<br />
[16:27:24] [Server thread/WARN]: server.properties does not exist<br />
[16:27:24] [Server thread/INFO]: Generating new properties file<br />
[16:27:24] [Server thread/WARN]: Failed to load eula.txt<br />
[16:27:24] [Server thread/INFO]: You need to agree to the EULA in order to run the server. Go to eula.txt for more info.</pre><br />
<br />
'''Stop minecraft and edit eula.txt'''<br />
<br />
Stop server so you can do the one time eula.txt agreement.<br />
<br />
<pre>$ service minecraft stop<br />
Stopping minecraft_server.jar<br />
minecraft_server.jar is stopped.<br />
<br />
[mineuser@localhost ~]$ cd minecraft/<br />
[mineuser@localhost minecraft]$ ls<br />
eula.txt logs minecraft_server.jar server.properties<br />
[mineuser@localhost minecraft]$ vi eula.txt</pre><br />
<br />
Change eula=false to eula=true<br />
<br />
'''Now start then stop minecraft'''<br />
<br />
Start server to generate server.properties file then stop server to edit.<br />
<br />
<pre><br />
[mineuser@localhost minecraft]$ service minecraft start<br />
Starting minecraft_server.jar...<br />
minecraft_server.jar is now running.<br />
[mineuser@localhost minecraft]$ service minecraft stop<br />
Stopping minecraft_server.jar<br />
minecraft_server.jar is stopped.<br />
[mineuser@localhost minecraft]$ vi server.properties</pre><br />
<br />
'''Final start'''<br />
<br />
<pre>[miner@localhost minecraft]$ service minecraft start<br />
Starting minecraft_server.jar...<br />
minecraft_server.jar is now running.</pre><br />
<br />
<br />
'''Using screen'''<br />
<br />
<pre><br />
[miner@localhost minecraft]$ screen -R<br />
<br />
<br />
[16:34:04] [Server thread/INFO]: Starting minecraft server version 1.8<br />
[16:34:04] [Server thread/INFO]: Loading properties<br />
[16:34:04] [Server thread/INFO]: Default game type: SURVIVAL<br />
[16:34:04] [Server thread/INFO]: Generating keypair<br />
[16:34:05] [Server thread/INFO]: Starting Minecraft server on *:25565<br />
[16:34:05] [Server thread/INFO]: Preparing level "world"<br />
[16:34:05] [Server thread/INFO]: Preparing start region for level 0<br />
[16:34:06] [Server thread/INFO]: Preparing spawn area: 8%<br />
[16:34:07] [Server thread/INFO]: Preparing spawn area: 58%<br />
[16:34:08] [Server thread/INFO]: Done (2.624s)! For help, type "help" or "?"</pre><br />
<br />
== Other Linux Links ==<br />
<br />
[http://minecraft.gamepedia.com/Server.properties server.properties] settings<br />
<br />
[http://minecraft.gamepedia.com/Tutorials/Server_startup_script Server start up script]<br />
<br />
[http://arstechnica.com/gaming/2012/09/blocks-with-friends-how-to-run-your-own-minecraft-server/3/ Running your own Minecraft server]<br />
<br />
[http://www.minecraftwiki.net/wiki/Setting_up_a_server#Linux_instructions Setting up server on Linux] from Minecraft wiki<br />
<br />
== Mods ==<br />
<br />
Haven't used mods.<br />
<br />
== How-to Minecraft Guides ==<br />
<br />
[[How To setup Minecraft server on Windows OS|How-to setup Minecraft server on Windows OS]]<br />
<br />
[[How-to edit server.properties file on Linux]]<br />
<br />
=== Backing up your Minecraft world ===<br />
<br />
This guide is written for:<br />
* Linux operating systems<br />
* uses /minecraft for Minecraft's root directory<br />
* starts and ends with Minecraft server running<br />
* connected to Linux server via SSH<br />
* connected to Minecraft server console<br />
* using byobu open source text-based window manager and terminal multiplexer<br />
* using Linux user anon with permissions on /minecraft and sub-directories and files<br />
* backups are stored in /minecraft/backups<br />
* removing old backups<br />
<br />
Backup steps:<br />
# Check no players are connected. Command: <code>/list</code><br />
# Save Minecraft world files. Command: <code>/save-all</code><br />
# Stop Minecraft server app. Command: <code>/stop</code><br />
# Switch to alternate terminal. Across the top of the SSH session, you will see <code>0:-*</code> for single terminal or <code>0:-* 1:--</code> for multiple terminals (the # represents each terminal, there can be many). The <code>*</code> indicates the terminal you are viewing. If single terminal, press F2 to create and switch to a new terminal. If multiple terminals, press F4 to move forward one terminal (F3 to move backward).<br />
# Verify you are using anon user. Prompt should start with <code>anon@</code> on Ubuntu Linux. You can also type <code>whoami</code> and the return should be <code>anon</code>.<br />
# Switch to Minecraft root directory. Command: <code>cd /minecraft</code><br />
# Show Minecraft worlds by listing directories and files in current directory. Command: <code>ls -l</code><br />
# Backup each world separately.<br />
## We will backup a world called '''realms''' in this example. <span style="color:red">Note: You will use the world name that is applicable to your current backup, don't always use '''realms'''.</span><br />
## You should see a '''realms''' directory from the previous command output.<br />
## This command will archive (create single file) and compress simultaneously so each world backup will be of a single file.<br />
## Use same command with different file names for each world backup.<br />
## Command template: <code>tar -cvzf newFileNameYYYYMMDD.tar.gz fileOrDirectoryToArchiveAndCompress/</code> where newFileName=worldName, fileOrDirectoryToArchiveAndCompress=realms, YYYY=2022, MM=01, and DD=03 if current date is January 3, 2022.<br />
## Command example: <code>tar -cvzf realms20220103.tar.gz realms/</code><br />
## The command should output the archival process and return to prompt when no errors are encountered.<br />
# Validate new backup exists.<br />
## Command: <code>ls -l</code><br />
## Verify a file exists matching your new file name, or <code>realms20220103.tar.gz</code> in our example.<br />
# Do the archive and compress command for each Minecraft world you want to backup.<br />
# Move backups to /minecraft/backups. Command: <code>mv ./*.tar.gz ./backups/</code><br />
# Validate backups are in /minecraft/backups. Command: <code>ls -l ./backups</code><br />
## You should see the backups you created in the output <span style=blue"color:">plus any pre-existing backups</span>.<br />
# Remove older backups when you have more than 3 of each world to save storage space.<br />
## Only backup worlds that have been played on since last backup.<br />
## Remove old backups. Command: <code>rm backups/water_world20220202.tar.gz</code> Copy and paste the file name after you type rm backups/ (highlight to copy and press middle mouse to paste should work) or use autocomplete (tab).<br />
# Switch to Minecraft terminal. F3 to move backward or F4 to move forward.<br />
# Start up Minecraft world like normal.<br />
<br />
<center>[[Gaming|To Gaming]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_TS_23.003_notes&diff=3040My 3GPP TS 23.003 notes2023-07-16T22:18:48Z<p>Paul: /* Subscription Concealed Identifier (SUCI) § 2.2B */</p>
<hr />
<div>== International Mobile Subscriber Identity (IMSI) § 2.2 ==<br />
<br />
IMSI is composed as shown:<br />
<br />
[[File:IMSI struct.png|IMSI struct]]<br />
<br />
IMSI is composed of three parts:<br />
# Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of the mobile subscription;<br />
# Mobile Network Code (MNC) consisting of two or three digits for 3GPP network applications. The MNC identifies the home PLMN of the mobile subscription within its country of domicile, or it identifies together with MCC and NID the mobile subscription's SNPN. The length of the MNC (two or three digits) depends on the value of the MCC. A mixture of two and three digit MNC codes within a single MCC area is not recommended and is outside the scope of 3GPP TS 23.003.<br />
# Mobile Subscriber Identification Number (MSIN) identifying the mobile subscription within a PLMN or SNPN.<br />
<br />
== Subscription Permanent Identifier (SUPI) § 2.2A ==<br />
<br />
The SUPI is a globally unique 5G Subscription Permanent Identifier allocated to each subscriber in the 5G System. It is defined in clause 5.9.2 of 3GPP TS 23.501.<br />
<br />
The SUPI is defined as:<br />
* a SUPI type: in this release of the specification, it may indicate an IMSI, a Network Specific Identifier (NSI), a Global Line Identifier (GLI) or a Global Cable Identifier (GCI); and<br />
* dependent on the value of the SUPI type:<br />
** an IMSI as defined in clause 2.1;<br />
** a Network Specific Identifier (NSI), taking the form of a Network Access Identifier (NAI) as defined in clause 28.7.2;<br />
** a Global Cable Identifier (GCI) taking the form of a NAI as defined in clause 28.15.2;<br />
** a Global Line Identifier (GLI) taking the form of an NAI as defined in clause 28.16.2.<br />
:NOTE: Depending on the protocol used to convey the SUPI, the SUPI type can take different formats.<br />
<br />
See clauses 4.7.2, 4.7.3 and 4.7.4 of 3GPP TS 23.316 for details on which types of SUPI are supported by 5G-BRG, FN-BRG, 5G-CRG and FN-CRG.<br />
<br />
== Subscription Concealed Identifier (SUCI) § 2.2B ==<br />
<br />
The SUCI is a privacy preserving identifier containing the concealed SUPI. It is defined in clause 6.12.2 of 3GPP TS 33.501.<br />
<br />
[[File:SUCI struct.png|SUCI struct]]<br />
<br />
The SUCI is composed of the following parts:<br />
:1) <span style="color:blue">SUPI Type</span>, consisting in a value in the range 0 to 7. It identifies the type of the SUPI concealed in the SUCI. The following values are defined:<br />
::- 0: IMSI<br />
::- 1: Network Specific Identifier (NSI)<br />
::- 2: Global Line Identifier (GLI)<br />
::- 3: Global Cable Identifier (GCI)<br />
::- 4 to 7: spare values for future use.<br />
:2) <span style="color:blue">Home Network Identifier</span>, identifying the home network of the subscriber.<br />
:When the SUPI Type is an IMSI, the Home Network Identifier is composed of two parts:<br />
::- Mobile Country Code (MCC), consisting of three decimal digits. The MCC identifies uniquely the country of domicile of the mobile subscription;<br />
::- Mobile Network Code (MNC), consisting of two or three decimal digits. The MNC identifies the home PLMN or SNPN of the mobile subscription.<br />
:When the SUPI type is a Network Specific Identifier (NSI), a GLI or a GCI, the Home Network Identifier consists of a string of characters with a variable length representing a domain name as specified in clause 2.2 of IETF RFC 7542. For a GLI or a GCI, the domain name shall correspond to the realm part specified in the NAI format for SUPI in clauses 28.15.2 and 28.16.2.<br />
:3) <span style="color:blue">Routing Indicator</span>, consisting of 1 to 4 decimal digits assigned by the home network operator and provisioned in the USIM, that allow together with the Home Network Identifier to route network signalling with SUCI to AUSF and UDM instances capable to serve the subscriber.<br />
:Each decimal digit present in the Routing Indicator shall be regarded as meaningful (e.g. value "012" is not the same as value "12"). If no Routing Indicator is configured on the USIM or the ME, this data field shall be set to the value 0 (i.e. only consist of one decimal digit of "0").<br />
:4) <span style="color:blue">Protection Scheme Identifier</span>, consisting in a value in the range of 0 to 15 (see Annex C.1 of 3GPP TS 33.501). It represents the null scheme or a non-null scheme specified in Annex C of 3GPP TS 33.501 or a protection scheme specified by the HPLMN; the null scheme shall be used if the SUPI type is a GLI or GCI.<br />
:5) <span style="color:blue">Home Network Public Key Identifier</span>, consisting in a value in the range 0 to 255. It represents a public key provisioned by the HPLMN or SNPN and it is used to identify the key used for SUPI protection. This data field shall be set to the value 0 if and only if null protection scheme is used;<br />
:6) <span style="color:blue">Scheme Output</span>, consisting of a string of characters with a variable length or hexadecimal digits, dependent on the used protection scheme, as defined below. It represents the output of a public key protection scheme specified in Annex C of 3GPP TS 33.501 or the output of a protection scheme specified by the HPLMN.<br />
<br />
Figure 2.2B-2 defines the scheme output for the null protection scheme. Figure recreated here:<br />
<br />
[[File:Scheme output for null protection scheme struct.png|Scheme output for null protection scheme struct]]<br />
<br />
The Mobile Subscriber Identification Number ("MSIN") is defined in clause 2.2; the "username" corresponds to the username part of a NAI, and it is applicable to SUPI types Network-Specific Identifier (clause 28.7.2), Global Line Identifier (GLI) (clause 28.16.2) or Global Cable Identifier (GCI) (clause 28.15.2).<br />
<br />
:NOTE 1: For a SUCI with SUPI Type 2 or 3 (i.e. GLI or GCI), the SUCI can, based on subscription information, act as a pseudonym of the actual SUPI containing an IMSI (see 3GPP TS 23.316 [131], clauses 4.7.3 and 4.7.4). If so, the UDM derives the actual SUPI (IMSI) from the de-concealed SUCI (GLI/GCI).<br />
<br />
An anonymous SUCI is composed by setting the SUPI Type field to 1 (Network-Specific Identifier), using the null protection scheme, and where the scheme output corresponds to a username set to either the "anonymous" string or to an empty string (see IETF RFC 7542, clause 2.4).<br />
<br />
The scheme output is formatted as a variable length of characters as specified for the username in clause 2.2 of IETF RFC 7542.<br />
<br />
:NOTE 2: If the null protection scheme is used, the NFs can derive SUPI from SUCI when needed. The AMF derives SUPI used for AUSF discovery from SUCI when the Routing-Indicator is zero and the protection scheme is null. For an anonymous SUCI, an NF can derive an anonymous SUPI from an anonymous SUCI when needed; this is, the NF can derive a SUPI in NAI format for which the "username" part of the SUPI is "anonymous" or omitted.<br />
<br />
== 2.4 Structure of Temporary Mobile Subscriber Identity (TMSI) and 5G-TMSI ==<br />
<br />
Since the TMSI has only local significance (i.e. within a VLR and the area controlled by a VLR, or within an SGSN and the area controlled by an SGSN, or within an MME and the area controlled by an MME), the structure and coding of it can be chosen by agreement between operator and manufacturer in order to meet local needs.<br />
<br />
The TMSI consists of 4 octets.<br />
<br />
The 5G-TMSI is also 4 octets (32 bits), local to one AMF, and uniquely identifies a UE within that AMF. The 5G-TMSI structure and coding format is operator and manufacturer dependent.<br />
<br />
== 5G Globally Unique Temporary Identity (5G-GUTI) § 2.10 ==<br />
<br />
=== Introduction § 2.10.1 ===<br />
The purpose of the 5G-GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the 5G System (5GS). It also allows the identification of the Access and Mobility Management Function (AMF) and network. It can be used by the network and the UE to establish the UE's identity during signalling between them in the 5GS. See 3GPP TS 23.501.<br />
<br />
The 5G-GUTI has two main components:<br />
* one that identifies the AMF(s) which allocated the 5G-GUTI; and<br />
* one that uniquely identifies the UE within the AMF(s) that allocated the 5G-GUTI.<br />
<br />
Within the AMF(s), the mobile shall be identified by the 5G-TMSI.<br />
<br />
The Globally Unique AMF Identifier (GUAMI) shall be constructed from the MCC, MNC and AMF Identifier (AMFI).<br />
<br />
The AMFI shall be constructed from an AMF Region ID, an AMF Set ID and an AMF Pointer. The AMF Region ID identifies the region, the AMF Set ID uniquely identifies the AMF Set within the AMF Region, and the AMF Pointer identifies one or more AMFs within the AMF Set.<br />
:NOTE: When the UE is assigned a 5G-GUTI with an AMF Pointer value used by more than one AMF, the AMFs need to ensure that the 5G-TMSI value used within the assigned 5G-GUTI is not already in use within the AMF's sharing that pointer value.<br />
<br />
The 5G-GUTI shall be constructed from the GUAMI and the 5G-TMSI.<br />
<br />
For paging purposes, the mobile is paged with the 5G-S-TMSI. The 5G-S-TMSI shall be constructed from the AMF Set ID, the AMF Pointer and the 5G-TMSI.<br />
<br />
The operator shall need to ensure that the combination of the AMF Set ID and AMF Pointer is unique within the AMF Region and, if overlapping AMF Regions are in use, unique within the area of overlapping AMF Regions.<br />
<br />
The 5G-GUTI shall be used to support subscriber identity confidentiality, and, in the shortened 5G-S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request).<br />
<br />
The format and size of the 5G-GUTI is therefore the following:<br />
<br />
<code><5G-GUTI> = <GUAMI><5G-TMSI></code>, where <code><GUAMI> = <MCC><MNC><AMF Identifier></code> and <code><AMF Identifier> = <AMF Region ID><AMF Set ID><AMF Pointer></code><br />
<br />
MCC and MNC shall have the same field size as in earlier 3GPP systems. See 3GPP TS 24.008 § 10.5.1.3 for details of MCC (12bits) and MNC (12 bits) size and formatting.<br />
<br />
5G-TMSI shall be of 32 bits length.<br />
<br />
AMF Region ID shall be of 8 bits length.<br />
<br />
AMF Set ID shall be of 10 bits length.<br />
<br />
AMF Pointer shall be of 6 bits length.<br />
<br />
Diagram:<br />
<br />
[[File:5G-GUTI struct.png|5G-GUTI struct]]<br />
<br />
== Structure of the 5G-Short-Temporary Mobile Subscriber Identity (5G-S-TMSI) § 2.11 ==<br />
The 5G-S-TMSI is the shortened form of the 5G-GUTI to enable more efficient radio signalling procedures (e.g. paging and Service Request). For paging purposes, the mobile is paged with the 5G-S-TMSI. The 5G-S-TMSI shall be constructed from the AMF Set ID, the AMF Pointer and the 5G-TMSI:<br />
<br />
<code><5G-S-TMSI> = <AMF Set ID><AMF Pointer><5G-TMSI></code><br />
<br />
Diagram:<br />
<br />
[[File:5G-S-TMSI struct.png|5G-S-TMSI structure]]<br />
<br />
== Definition of Access Point Name § 9 ==<br />
In the GPRS backbone, an Access Point Name (APN) is a reference to a GGSN. To support inter-PLMN roaming, the internal GPRS DNS functionality is used to translate the APN into the IP address of the GGSN.<br />
<br />
== Definition of Data Network Name § 9A ==<br />
In 5GS, the Data Network Name (DNN) is equivalent to an APN in EPS. The DNN is a reference to a data network, it may be used e.g. to select SMF or UPF.<br />
<br />
The requirements for APN in clause 9 shall apply for DNN in a 5GS as well.<br />
<br />
== NR Cell Identity (NCI) and NR Cell Global Identity (NCGI) § 19.6A ==<br />
The NR Cell Global Identity (NCGI) shall be composed of the concatenation of the PLMN Identifier (PLMN-Id) and the NR Cell Identity (NCI) as shown in figure 19.6A-1 and shall be globally unique:<br />
<br />
MCC + MNC + NCI<br />
<br />
The NCI shall be of fixed length of 36 bits and shall be coded using full hexadecimal representation. The exact coding of the NCI is the responsibility of each PLMN operator.<br />
For more details on NCI and NCGI, see 3GPP TS 38.413.<br />
<br />
NOTE: In the 5G Core Network protocols, when the NCGI needs to be identified in the context of Standalone Non-Public Networks (SNPN), the Network Identifier (NID) of the SNPN is included as part of the NCGI Information Element (see 3GPP TS 29.571); this is a protocol aspect that does not imply any change on the system-wide definition of the NCGI.<br />
<br />
== Numbering, addressing and identification for 5G System (5GS) § 28 ==<br />
<br />
=== Introduction § 28.1 ===<br />
This clause describes the format of the parameters, identifiers and information used for the 5G system. For further information on these, see 3GPP TS 23.501, 3GPP TS 23.502 and 3GPP TS 23.503.<br />
<br />
NAI format for SUPI see § 28.7.2<br />
<br />
NAI format for SUCI see § 28.7.3<br />
<br />
NAI format for 5G-GUTI see § 28.7.8<br />
<br />
<center>[[Telecommunications info|To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_33.501_notes&diff=3039My 3GPP 33.501 notes2023-07-16T17:57:23Z<p>Paul: /* C.2 Null-scheme */</p>
<hr />
<div>== § 1 Scope ==<br />
<br />
This document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
== Definitions ==<br />
=== 5G security context===<br />
The state that is established locally at the UE and a serving network domain and represented by the "5G security context data" stored at the UE and a serving network.<br />
<br />
NOTE 1: The "5G security context data" consists of the 5G NAS security context, and the 5G AS security context for 3GPP access and/or the 5G AS security context for non-3GPP access.<br />
<br />
NOTE 2: A 5G security context has type "mapped", "full native" or "partial native". Its state can either be "current" or "non-current". A context can be of one type only and be in one state at a time. The state of a particular context type can change over time. A partial native context can be transformed into a full native. No other type transformations are possible. <br />
<br />
=== 5G AS security context for 3GPP access ===<br />
The cryptographic keys at AS level with their identifiers, the Next Hop parameter (NH), the Next Hop Chaining Counter parameter (NCC) used for next hop access key derivation, the identifiers of the selected AS level cryptographic algorithms, the UE security capabilities, and the UP Security Policy at the network side, UP security activation status and the counters used for replay protection. <br />
<br />
NOTE 3: NH and NCC need to be stored also at the AMF during connected mode.<br />
<br />
NOTE 4: UP security activation status is sent from gNB/ng-eNB in step 1b in clause 6.6.2 corresponding to the active PDU session(s).<br />
<br />
=== 5G AS security context for non-3GPP access ===<br />
The key KN3IWF, the cryptographic keys, cryptographic algorithms and tunnel security association parameters used at IPsec layer for the protection of IPsec SA.<br />
<br />
=== 5G AS Secondary Cell security context ===<br />
The cryptographic keys at AS level for secondary cell with their identifiers, the identifier of the selected AS level cryptographic algorithms for secondary cell, the UP Security Policy at the network side, and counters used for replay protection.<br />
<br />
=== Home Network Public Key Identifier ===<br />
An identifier used to indicate which public/private key pair is used for SUPI protection and de-concealment of the SUCI.<br />
<br />
=== subscription credential(s) ===<br />
The set of values in the USIM and in the home operator's network, consisting of at least the long-term key(s) and the subscription identifier SUPI, used to uniquely identify a subscription and to mutually authenticate the UE and 5G core network.<br />
<br />
=== subscription identifier de-concealing function ===<br />
The Subscription Identifier De-concealing Function (SIDF) service offered by the network function UDM in the home network of the subscriber responsible for de-concealing the SUPI from the SUCI.<br />
<br />
=== UE 5G security capability ===<br />
The UE security capabilities for 5G AS and 5G NAS.<br />
<br />
=== UE security capabilities ===<br />
The set of identifiers corresponding to the ciphering and integrity algorithms implemented in the UE.<br />
<br />
NOTE 9: This includes capabilities for NG-RAN and 5G NAS, and includes capabilities for EPS, UTRAN and GERAN if these access types are supported by the UE.<br />
<br />
== Security Domains § 4.1 ==<br />
<br />
* '''Network access security (I)''': the set of security features that enable a UE to authenticate and access services via the network securely, including the 3GPP access and Non-3GPP access, and in particularly, to protect against attacks on the (radio) interfaces. In addition, it includes the security context delivery from SN to AN for the access security. <br />
* '''Network domain security (II)''': the set of security features that enable network nodes to securely exchange signalling data and user plane data. <br />
* '''User domain security (III)''': the set of security features that secure the user access to mobile equipment.<br />
* '''Application domain security (IV)''': the set of security features that enable applications in the user domain and in the provider domain to exchange messages securely. Application domain security is out of scope of the present document.<br />
* '''SBA domain security (V)''': the set of security features that enables network functions of the SBA architecture to securely communicate within the serving network domain and with other network domains . Such features include network function registration, discovery, and authorization security aspects, as well as the protection for the service-based interfaces. SBA domain security is a new security feature compared to TS 33.401.<br />
* '''Visibility and configurability of security (VI)''': the set of features that enable the user to be informed whether a security feature is in operation or not.<br />
<br />
== The 5G System architecture introduces the following security entities in the 5G Core network § 4.3 ==<br />
* AUSF: AUthentication Server Function;<br />
* ARPF: Authentication credential Repository and Processing Function;<br />
* SIDF: Subscription Identifier De-concealing Function;<br />
* SEAF: SEcurity Anchor Function.<br />
<br />
== General Security Requirements § 5.1 ==<br />
<br />
=== Mitigation of bidding down attacks § 5.1.1 ===<br />
<br />
An attacker could attempt a bidding down attack by making UE and the network entities respectively believe that the other side does not support a security feature, even when both sides support security feature. It shall be ensured that a bidding down attack, in the above sense, can be prevented.<br />
<br />
=== Authentication and Authorization § 5.1.2 ===<br />
The 5G system shall satisfy the following requirements.<br />
<br />
<span style="color:red">'''Subscription authentication</span>:''' The serving network shall authenticate the Subscription Permanent Identifier (SUPI) in the process of authentication and key agreement between UE and network.<br />
<br />
'''Serving network authentication:''' The UE shall authenticate the serving network identifier through implicit key authentication. <br />
:NOTE 1: The meaning of 'implicit key authentication' here is that authentication is provided through the successful use of keys resulting from authentication and key agreement in subsequent procedures. <br />
:NOTE 2: The preceding requirement does not imply that the UE authenticates a particular entity, e.g. an AMF, within a serving network. <br />
<br />
'''UE authorization:''' The serving network shall authorize the UE through the subscription profile obtained from the home network. UE authorization is based on the authenticated SUPI.<br />
<br />
'''Serving network authorization by the home network:''' Assurance shall be provided to the UE that it is connected to a serving network that is authorized by the home network to provide services to the UE. This authorization is 'implicit' in the sense that it is implied by a successful authentication and key agreement run.<br />
<br />
'''Access network authorization:''' Assurance shall be provided to the UE that it is connected to an access network that is authorized by the serving network to provide services to the UE. This authorization is 'implicit' in the sense that it is implied by a successful establishment of access network security. This access network authorization applies to all types of access networks.<br />
<br />
'''Unauthenticated Emergency Services:''' In order to meet regulatory requirements in some regions, the 5G system shall support unauthenticated access for emergency services. This requirement applies to all MEs and only to those serving networks where regulatory requirements for unauthenticated emergency services exist. Serving networks located in regions where unauthenticated emergency services are forbidden shall not support this feature.<br />
<br />
== Requirements of UE § 5.2 ==<br />
<br />
=== Subscriber privacy § 5.2.5 ===<br />
<br />
The UE shall support 5G Globally Unique Temporary Identifier (5G-GUTI).<br />
<br />
The SUPI '''''should not''''' be transferred in clear text over NG-RAN except routing information, e.g. Mobile Country Code (MCC) and Mobile Network Code (MNC).<br />
<br />
The Home Network Public Key shall be stored in the Universal Subscriber Identity Module (USIM). <br />
<br />
The protection scheme identifier shall be stored in the USIM.<br />
<br />
The Home Network Public Key Identifier shall be stored in the USIM.<br />
<br />
The SUCI calculation indication, either USIM or Mobile Equipment (ME) calculating the SUCI, shall be stored in USIM.<br />
<br />
<span style="color:red">The Mobile Equipment (ME) shall support the null-scheme. If the home network has not provisioned the Home Network Public Key in USIM, the SUPI protection in initial registration procedure is not provided. In this case, the null-scheme shall be used by the ME.</span><br />
<br />
Based on home operator's decision, indicated by the USIM, the calculation of the SUCI shall be performed either by the USIM or by the Mobile Equipment (ME).<br />
<br />
:NOTE 1: If the SUCI calculation indication is not present, the calculation is in the ME.<br />
<br />
<span style="color:red">In case of an unauthenticated emergency call, privacy protection for SUPI is not required</span>.<br />
<br />
Provisioning, and updating the Home Network Public Key, Home Network Public Key Identifier, protection scheme identifier, Routing Indicator, and SUCI calculation indication in the USIM shall be in the control of the home network operator. <br />
<br />
:NOTE 2: The provisioning and updating of the Home Network Public Key, Home Network Public Key Identifier, protection scheme identifier, and SUCI calculation indication is out of the scope of the present document. It can be implemented using, e.g. the Over the Air (OTA) mechanism. Routing Indicator can be updated, e.g., by OTA or as defined in clause 6.15. <br />
<br />
Subscriber privacy enablement shall be under the control of the home network of the subscriber. <br />
<br />
The UE shall only send the PEI in the NAS protocol after NAS security context is established, unless during emergency registration when no NAS security context can be established.<br />
<br />
The Routing Indicator shall be stored in the USIM. If the Routing Indicator is not present in the USIM, the ME shall set it to a default value as defined in TS 23.003.<br />
<br />
== Requirements of AMF § 5.5 ==<br />
<br />
=== Subscriber privacy § 5.5.3 ===<br />
The AMF shall support to trigger primary authentication using the SUCI.<br />
The AMF shall support assigning 5G-GUTI to the UE.<br />
The AMF shall support reallocating 5G-GUTI to UE.<br />
The AMF shall be able to confirm SUPI from UE and from home network. The AMF shall deny service to the UE if this confirmation fails.<br />
<br />
== Requirements on SEAF § 5.6 ==<br />
<br />
The security anchor function (SEAF) provides the authentication functionality via the AMF in the serving network.<br />
<br />
The SEAF shall fulfil the following requirements:<br />
* The SEAF shall support primary authentication using SUCI.<br />
<br />
== Requirements of UDM § 5.8 ==<br />
<br />
=== Subscriber privacy related requirements to UDM and SIDF § 5.8.2 ===<br />
The SIDF is responsible for de-concealment of the SUCI and shall fulfil the following requirements:<br />
* The SIDF shall be a service offered by UDM.<br />
* The SIDF shall resolve the SUPI from the SUCI based on the protection scheme used to generate the SUCI. <br />
<br />
The Home Network Private Key used for subscriber privacy shall be protected from physical attacks in the UDM. <br />
<br />
The UDM shall hold the Home Network Public Key Identifier(s) for the private/public key pair(s) used for subscriber privacy.<br />
<br />
The algorithm used for subscriber privacy shall be executed in the secure environment of the UDM.<br />
<br />
=== Requirements on AUSF § 5.8a ===<br />
The Authentication server function (AUSF) shall handle authentication requests for both, 3GPP access and non-3GPP access.<br />
<br />
The AUSF shall provide SUPI to the VPLMN only after authentication confirmation if authentication request with SUCI was sent by VPLMN.<br />
<br />
The AUSF shall inform the UDM that a successful or unsuccessful authentication of a subscriber has occurred.<br />
<br />
== Security procedures between UE and 5G network functions § 6 ==<br />
<br />
6.1 Primary authentication and key agreement<br />
<br />
6.1.1 Authentication framework<br />
<br />
=== General § 6.1.1.1 ===<br />
<br />
The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key agreement procedure results in an anchor key called the K<sub>SEAF</sub> provided by the AUSF of the home network to the SEAF of the serving network.<br />
<br />
Keys for more than one security context can be derived from the K<sub>SEAF</sub> without the need of a new authentication run. A concrete example of this is that an authentication run over a 3GPP access network can also provide keys to establish security between the UE and a N3IWF used in untrusted non-3GPP access.<br />
<br />
The anchor key K<sub>SEAF</sub> is derived from an intermediate key called the K<sub>AUSF</sub>. The K<sub>AUSF</sub> is established between the UE and HN resulting from the primary authentication procedure. The K<sub>AUSF</sub> may be securely stored in the AUSF based on the home operator's policy on using such key e.g. if the control plane solution for Steering of Roaming (see clause 6.14) or UE Parameter Update procedures (see clause 6.15) or Authentication and Key Management for Applications (AKMA) are supported by the HPLMN.<br />
<br />
NOTE A: For standalone non-public networks when an authentication method other than 5G Authentication and Key Agreement (AKA) or Extensible Authentication Protocol AKA (EAP-AKA') is used, Annex I.2 applies.<br />
<br />
NOTE 1: This feature is an optimization that might be useful, for example, when a UE registers to different serving networks for 3GPP-defined access and untrusted non-3GPP access (this is possible according to TS 23.501 [2]). The details of this feature are operator-specific and not in scope of this document.<br />
<br />
NOTE 2: A subsequent authentication based on the K<sub>AUSF</sub> stored in the AUSF gives somewhat weaker guarantees than an authentication directly involving the ARPF and the USIM. It is rather comparable to fast re-authentication in EAP-AKA'.<br />
<br />
UE and serving network shall support EAP-AKA' and 5G AKA authentication methods.<br />
<br />
NOTE 2b: It is the home operator's decision which authentication method is selected.<br />
<br />
The USIM shall reside on a UICC. The UICC may be removable or non-removable.<br />
<br />
NOTE 3: For non-3GPP access networks USIM applies in case of terminal with 3GPP access capabilities.<br />
<br />
If the terminal supports 3GPP access capabilities, the credentials used with EAP-AKA' and 5G AKA for non-3GPP access networks shall reside on the UICC.<br />
<br />
NOTE 4: EAP-AKA' and 5G AKA are the only authentication methods that are supported in UE and serving network, hence only they are described in sub-clause 6.1.3 of the present document. For a private network using the 5G system as specified in [7] an example of how additional authentication methods can be used with the EAP framework is given in the informative Annex B. <br />
<br />
NOTE 5: For non-public network (NPN) security the Annex I of the present document provides details.<br />
<br />
Upon successful completion of the 5G AKA primary authentication, the AMF shall initiate NAS security mode command procedure (see clause 6.7.2) with the UE.<br />
<br />
NOTE 6: The reason to mandatory run the NAS SMC procedure after primary authentication is because the UE does not store the new derived K<sub>AUSF</sub> until receiving the NAS SMC message. The new partial native NAS security context is taken into use. It is specified in clause 6.9.4.4 whether AS key re-keying is performed.<br />
<br />
=== EAP framework § 6.1.1.2 ===<br />
<br />
The EAP framework is specified in RFC 3748. It defines the following roles: peer, pass-through authenticator and back-end authentication server. The back-end authentication server acts as the EAP server, which terminates the EAP authentication method with the peer. In the 5G system, the EAP framework is supported in the following way:<br />
* The UE takes the role of the peer. <br />
* The SEAF takes the role of pass-through authenticator. <br />
*The AUSF takes the role of the backend authentication server.<br />
<br />
=== Construction of the serving network name § 6.1.1.4 ===<br />
<br />
See specification. Format is 5G.<SN Id> where 5G represents service code and <SN Id> is Serving Network Identifier.<br />
<br />
== 6.3 Security Contexts ==<br />
<br />
=== 6.3.2 Multiple registrations in same or different serving networks ===<br />
<br />
==== 6.3.2.0 General ====<br />
<br />
There are two cases where the UE can be multiple registered in different PLMN's serving networks or in the same PLMN's serving networks. The first case is when the UE is registered in one PLMN serving network over a certain type of access (e.g. 3GPP) and is registered to another PLMN serving network over the other type of access (e.g. non-3GPP). The second case is where the UE is registered in the same AMF in the same PLMN serving network over both 3GPP and non-3GPP accesses. The UE will establish two NAS connections with the network in both cases.<br />
:NOTE: The UE uses the same subscription credential(s) for multiple registrations in the same or different serving networks.<br />
<br />
==== 6.3.2.1 Multiple registrations in different PLMNs ====<br />
The UE shall independently maintain and use two different 5G security contexts, one per PLMN's serving network. Each security context shall be established separately via a successful primary authentication procedure with the Home PLMN.<br />
<br />
The ME shall store the two different 5G security contexts on the USIM if the USIM supports the 5G parameters storage. If the USIM does not support the 5G parameters storage, then the ME shall store the two different 5G security contexts in the ME non-volatile memory. Both of the two different 5G security contexts are current 5G security context.<br />
<br />
The latest K<sub>AUSF</sub> result of the successful completion of the latest primary authentication shall be used by the UE and the HN regardless over which access network type (3GPP or non-3GPP) it was generated.<br />
<br />
The HN shall keep the latest K<sub>AUSF</sub> generated during successful authentication over a given access even if the UE is deregistered from that access, but the UE is registered via another access.<br />
<br />
==== 6.3.2.2 Multiple registrations in the same PLMN ====<br />
<br />
When the UE is registered in the same AMF in the same PLMN serving network over both 3GPP and non-3GPP accesses, the UE shall establish two NAS connections with the network. Upon receiving the registration request message, the AMF should check whether the UE is authenticated by the network. The AMF may decide to skip a new authentication run in case there is an available 5G security context for this UE by means of 5G-GUTI, e.g. when the UE successfully registered to 3GPP access.<br />
<br />
If the UE registers to the same AMF via non-3GPP access, the AMF can decide not to run a new authentication if it has an available security context to use. In this case, the UE shall directly take into use the available common 5G NAS security context and use it to protect the registration over the non-3GPP access. If there are stored NAS counts for the non-3GPP access for the PLMN in the UE, then the stored NAS counts for the non-3GPP access for the PLMN shall be used to protect the registration over the non-3GPP access. Otherwise, the common 5G NAS security context is taken into use for the first time (partial) over non-3GPP access. In this case, the UL NAS COUNT value and DL NAS COUNT value for the non-3GPP access needs to be set to zero by the UE before the UE is taking the 5G NAS security context into use over non 3GPP access.<br />
<br />
The AMF and the UE shall establish a common NAS security context consisting of a single set of NAS keys and algorithm at the time of first registration over any access. The AMF and the UE shall also store parameters specific to each NAS connection in the common NAS security context including two pairs of NAS COUNTs for each access (i.e. 3GPP access and non-3GPP access). The connection specific parameters are specified in clause 6.4.2.2 of the present document. <br />
<br />
== 6.4 NAS security mechanisms ==<br />
<br />
=== 6.4.1 General ===<br />
<br />
This sub-clause describes the security mechanisms for the protection of NAS signalling and data between the UE and the AMF over the N1 reference point. This protection involves both integrity and confidentiality protection. The security parameters for NAS protection are part of the <span style="color:red">5G security context</span> described in sub-clause 6.3 of the present document.<br />
<br />
=== 6.4.2 Security for multiple NAS connections ===<br />
<br />
==== 6.4.2.1 Multiple active NAS connections with different PLMNs ====<br />
<br />
TS 23.501 has a scenario when the UE is registered to a VPLMN's serving network via 3GPP access and to another VPLMN's or HPLMN's serving network via non-3GPP access at the same time. When the UE is registered in one PLMN's serving network over a certain type of access (e.g. 3GPP) and is registered to another PLMN's serving network over another type of access (e.g. non-3GPP), then the UE has two active NAS connections with different AMF's in different PLMNs. As described in clause 6.3.2.1, the UE shall independently maintain and use two different 5G security contexts, one per PLMN serving network. The 5G security context maintained by the UE shall contain the full set of 5G parameters, including NAS context parameters for 3GPP and non-3GPP access types per PLMN. In case of connection to two different PLMNs, it is necessary to maintain a complete 5G NAS security context for each PLMN independently, each with all associated parameters (such as two pairs of NAS COUNTs, i.e. one pair for 3GPP access and one pair for non-3GPP access).<br />
<br />
Each security context shall be established separately via a successful primary authentication procedure with the Home PLMN. <br />
<br />
All the NAS and AS security mechanisms defined for single registration mode are applicable independently on each access using the corresponding 5G security context.<br />
<br />
:NOTE: The UE belongs to a single HPLMN.<br />
<br />
==== 6.4.2.2 Multiple active NAS connections in the same PLMN's serving network ====<br />
<br />
When the UE is registered in a serving network over two types of access (e.g. 3GPP and non-3GPP), then the UE has two active NAS connections with the same AMF. A common 5G NAS security context is created during the registration procedure over the first access type.<br />
<br />
In order to realize cryptographic separation and replay protection, the common NAS security-context shall have parameters specific to each NAS connection. The connection specific parameters include a pair of NAS COUNTs for uplink and downlink and unique NAS connection identifier. The value of the unique NAS connection identifier shall be set to "0x01" for 3GPP access and set to "0x02" for non-3GPP access. All other parameters as e.g. algorithm identifiers in the common NAS security context are common to multiple NAS connections.<br />
<br />
In non-mobility cases, when the UE is simultaneously registered over both types of accesses, and if NAS key re-keying as described in clause 6.9.4.2 or if NAS key refresh as described in clause 6.9.4.3 takes place over one of the accesses (say access A):<br />
# If the other access (access B) is in CM-CONNECTED state, then the new NAS security context shall only be activated over that access (access A). The UE and the AMF shall not change the NAS security context in use on the other access (say access B). In order to activate the new NAS security context over the other access (access B), the AMF shall trigger a NAS Security Mode Command (SMC) run over that access either in the current running procedure or a subsequent NAS procedure. During the second NAS SMC run (on access B), the AMF shall include the same ngKSI associated with the new NAS security context and the same algorithm choices as for the first access. After a successful second NAS SMC procedure over the other access (access B), both the UE and the AMF shall delete the old NAS security context.<br />
# Whenever the AMF sends a NAS SMC over access (access A) and AMF considers the UE to not be in CM-CONNECTED state on the other access (access B), the AMF shall additionally activate (if not already in use on the other access) the security context that is active on the other accesses. Similarly, whenever the UE receives a NAS SMC over the access (access A) and UE is not in CM-CONNECTED state on the other access (access B), the UE additionally activates (if not already in use on the other access) the security context on the other access.<br />
<br />
In case of 3GPP access mobility or interworking with EPS, the following procedures apply:<br />
<ol type="1"><br />
<li>If the UE is in CM-CONNECTED state on the non-3GPP access, then:</li><br />
<ol type="a"><br />
<li>if the AMF does not have the security context the UE is using on the non-3GPP access (e.g. K<sub>AMF</sub> change on 3GPP access when the AMF changes), then in order to activate the same NAS security context that is in use over the 3GPP access the AMF shall run a NAS SMC procedure on the non-3GPP access; or</li><br />
<li>in the case of handover from EPS, then a mapped context will be in use on the 3GPP access and a different security context will be active on the non-3GPP access. To align the security contexts in use over both accesses, the AMF shall run a NAS SMC procedure over one access to take into use on that access the security context that is in use on the other access. In the case that a native security context is in use on the non-3GPP access, then the NAS SMC procedure shall be on the 3GPP access to take the native security context into use.</li></ol><br />
<li>Whenever the AMF sends a Registration Accept over the 3GPP access and AMF considers the UE to not be in CM-CONNECTED state on the non-3GPP access, the AMF shall activate (if not already in use on the non-3GPP access) the security context that is in use on the 3GPP access on the non-3GPP access. The AMF shall keep a native security context that was in use on non-3GPP access if the security context in use on the 3GPP access is a mapped security context. In order to take this native security context into use, the AMF shall run a NAS SMC procedure.</li><br />
</ol><br />
:::Similarly, whenever the UE receives a Registration Accept over the 3GPP access and UE is not in CM-CONNECTED state on the non-3GPP access, the UE activates (if not already in use on the non-3GPP access) the security context that is in use on the 3GPP access on the non-3GPP access. The UE shall keep a native security context that was in use on non-3GPP access if the security context in use on the 3GPP access is a mapped security context.<br />
<br />
To recover from a failure to align the NAS security contexts due to a state mis-match between AMF and UE, the AMF can align the security contexts in use on the 3GPP and non-3GPP access using the a NAS SMC procedure during a subsequent registration procedure (that was either initiated by the UE or sent in response to a Service Reject if the UE sends a Service Request).<br />
=== 6.4.3 NAS integrity mechanisms ===<br />
<br />
See spec for details...<br />
<br />
==== 6.4.3.0 General ====<br />
Integrity protection for NAS signalling messages shall be provided as part of the NAS protocol.<br />
<br />
=== 6.4.4 NAS confidentiality mechanisms ===<br />
<br />
See spec for details...<br />
<br />
==== 6.4.4.0 General ====<br />
Confidentiality protection for NAS signalling messages shall be provided as part of the NAS protocol.<br />
<br />
==== 6.4.5 Handling of NAS COUNTs ====<br />
<br />
See spec for details...<br />
<br />
=== 6.4.6 Protection of initial NAS message ===<br />
<span style="color:red">The initial NAS message is the first NAS message that is sent after the UE transitions from the idle state</span>. The UE shall send <span style="color:red">a limited set of IEs (called the cleartext IEs) including those needed to establish security in the initial message when it has no NAS security context</span>.<br />
<br />
<span style="color:red">When the UE has a NAS security context, the UE shall send a message that has the complete initial NAS message ciphered in a NAS Container along with the cleartext IEs with whole message integrity protected.</span><br />
<br />
The complete initial message is included in the NAS Security Mode Complete (SMC) message in a NAS Container when needed (e.g. AMF cannot find the used security context) in the latter case and always in the former case as described below.<br />
<br />
:Note: See 3GPP TS 24.501 5.4.2 for Security Mode Control procedure or [[My 3GPP 24.501 notes#5.4.2 Security mode control (SMC) procedure|my security mode control notes]]<br />
<br />
In case the UE selects a PLMN other than Registered PLMN/EPLMN in the 5GMM-IDLE state and the UE has a NAS security context containing the NEA0, then the UE shall discard the NAS security context and shall follow the procedure specified in this clause for protection of initial NAS message.<br />
<br />
The protection of the initial NAS message proceeds as shown in Figure 6.4.6-1 and following.<br />
<br />
[[File:Protecting initial NAS message.png|center|Protecting initial NAS message]]<br />
<br />
Step 1: The UE shall send the initial NAS message to the AMF.<br />
* If the UE has no NAS security context, the initial NAS message shall only contain the <span style="color:red">cleartext IEs, i.e. subscription identifiers (e.g. SUCI or GUTIs)</span>, UE security capabilities, ngKSI, indication that the UE is moving from EPC, Additional GUTI, and IE containing the TAU Request in the case idle mobility from LTE.<br />
*If the UE has a NAS security context, the <span style="color:red">message sent shall contain the information given above in cleartext and the complete initial NAS message ciphered in a NAS container</span> which is ciphered. With a NAS security context, the sent message shall also be integrity protected. In the case that the initial NAS message was protected and the AMF has the same security context, then steps 2 to 4 may be omitted In this case the AMF shall use the complete initial NAS message that is in the NAS container as the message to respond to..<br />
<br />
Step 2: If the AMF is not able to find the security context locally or from last visited AMF, or if the integrity check fails, then the AMF shall initiate an authentication procedure with the UE. If the AMF fetches old security context from the last visited AMF, the AMF may decipher the NAS container with the same security context, and get the initial NAS message, then the step 2b to 4 may be omitted. If the AMF fetches new K<sub>AMF</sub> from the last visited AMF (receiving keyAmfChangeInd), the step 2b may be omitted.<br />
<br />
Step 3: If the authentication of the UE is successful, the AMF shall send the NAS Security Mode Command message. If the initial NAS message was protected but did not pass the integrity check (due either to a MAC failure or the AMF not being able to find the used security context) or the AMF could not decrypt the complete initial NAS message in the NAS container (due to receiving "keyAmfChangeInd" from the last visited AMF), then the AMF shall include in the Security Mode Command message a flag requesting the UE to send the complete initial NAS message in the NAS Security Mode Complete message. <br />
<br />
Step 4: The UE shall send the NAS Security Mode Complete message to the network in response to a NAS Security Mode Command message. The NAS Security Mode Complete message shall be ciphered and integrity protected. Furthermore the NAS Security Mode Complete message shall include the complete initial NAS message in a NAS Container if either requested by the AMF or the UE sent the initial NAS message unprotected. The AMF shall use the complete initial NAS message that is in the NAS container as the message to respond to. <br />
<br />
Step 5: <span style="color:red">The AMF shall send its response to the Initial NAS message. This message shall be '''ciphered and integrity''' protected</span>.<br />
<br />
=== 6.4.7 Security aspects of SMS over NAS ===<br />
Specific services of SMS over NAS are defined in TS 23.501, and procedures for SMS over NAS are specified in TS 23.502.<br />
<br />
For registration and de-registration procedures for SMS over NAS, the details are specified in subclause 4.13.3.1 and 4.13.3.2 in TS 23.502. The NAS message can be protected by NAS security mechanisms.<br />
<br />
For MO/MT SMS over NAS via 3GPP/non-3GPP when the UE has already activated NAS security with the AMF before sending/receiving SMS, the NAS Transport message shall be ciphered and integrity protected using the NAS security context by the UE/AMF as described in sub-clause 6.4 in the present document.<br />
<br />
== 6.5 RRC security mechanisms ==<br />
<br />
See spec for details...<br />
<br />
== 6.7 Security algorithm selection, key establishment and security mode command procedure ==<br />
<br />
=== 6.7.1 Procedures for NAS algorithm selection ===<br />
<br />
==== 6.7.1.1 Initial NAS security context establishment ====<br />
Each AMF shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered according to a priority decided by the operator.<br />
<br />
To establish the NAS security context, the AMF shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm. The AMF shall then initiate a NAS security mode command procedure, and include the chosen algorithm and UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see sub-clause 6.7.2 of the present document). The AMF shall select the NAS algorithm which have the highest priority according to the ordered lists.<br />
<br />
==== 6.7.1.2 AMF change ====<br />
If the change of the AMF at N2-Handover or mobility registration update results in the change of algorithm to be used for establishing NAS security, the target AMF shall indicate the selected algorithm to the UE as defined in Clause 6.9.2.3.3 for N2-Handover (i.e., using NAS Container) and Clause 6.9.3 for mobility registration update (i.e., using NAS SMC). The AMF shall select the NAS algorithm which has the highest priority according to the ordered lists (see sub-clause 6.7.1.1 of the present document).<br />
<br />
=== 6.7.2 NAS security mode command procedure ===<br />
<br />
See spec for details...<br />
<br />
== 6.12 Subscription identifier privacy ==<br />
<br />
=== 6.12.1 Subscription permanent identifier ===<br />
<span style="color:red">In the 5G system, the globally unique 5G subscription permanent identifier is called SUPI as defined in 3GPP TS 23.501. The SUCI is a privacy preserving identifier containing the concealed SUPI.</span><br />
<br />
<span style="color:red">The SUPI is privacy protected over-the-air by using the SUCI</span> which is described in clause 6.12.2. Handling of SUPI and privacy provisioning related to concealing the SUPI shall be done according to the requirements specified in clause 5 and details provided in clause 6.12.2.<br />
<br />
=== 6.12.2 Subscription concealed identifier ===<br />
<br />
;subscription concealed identifier: A one-time use subscription identifier, called the SUbscription Concealed Identifier (SUCI), which contains the Scheme-Output, and additional non-concealed information needed for home network routing and protection scheme usage.<br />
<br />
The SUbscription Concealed Identifier, called SUCI, is a privacy preserving identifier containing the concealed SUPI.<br />
<br />
The UE shall generate a SUCI using a protection scheme with the raw public key, i.e. the Home Network Public Key, that was securely provisioned in control of the home network. The protection schemes shall be the ones specified in Annex C of this document or the ones specified by the HPLMN.<br />
<br />
The UE shall construct a scheme-input from the subscription identifier part of the SUPI as follows:<br />
* For SUPIs containing IMSI, the subscription identifier part of the SUPI includes the MSIN of the IMSI as defined in TS 23.003. <br />
* For SUPIs taking the form of a NAI, the subscription identifier part of the SUPI includes the "username" portion of the NAI as defined in NAI RFC 7542.<br />
<br />
The UE shall execute the protection scheme with the constructed scheme-input as input and take the output as the Scheme Output.<br />
<br />
The UE shall not conceal the Home Network Identifier and the Routing Indicator.<br />
<br />
For SUPIs containing IMSI, the UE shall construct the SUCI with the following data fields:<br />
* The SUPI Type as defined in TS 23.003 identifies the type of the SUPI concealed in the SUCI.<br />
* The Home Network Identifier is set to the MCC and MNC of the IMSI as specified in 23.003.<br />
* The Routing Indicator as specified in TS 23.003.<br />
* The Protection Scheme Identifier as specified in Annex C of this specification.<br />
* The Home Network Public Key Identifier as specified in this document and detailed in TS 23.003.<br />
* The Scheme Output as specified in this document and detailed in TS 23.003.<br />
<br />
For SUPIs containing Network Specific Identifier, the UE shall construct the SUCI in NAI format with the following data fields:<br />
* realm part of the SUCI is set to the realm part of the SUPI.<br />
* username part of the SUCI is formatted as specified in TS 23.003 using the SUPI Type, Routing Indicator, the Protection Scheme Identifier, the Home Network Public Key Identifier and the Scheme Output.<br />
:NOTE 1: The format of the SUPI protection scheme identifiers is defined in Annex C. <br />
:NOTE 2: The identifier and the format of the Scheme Output are defined by the protection schemes in Annex C. In case of non-null-schemes, the freshness and randomness of the SUCI will be taken care of by the corresponding SUPI protection schemes.<br />
:NOTE 2a: In case of null-scheme being used, the Home Network Public Key Identifier is set to a default value as described in TS 23.003.<br />
<br />
<span style="color:red">The UE shall include a SUCI only in the following 5G NAS messages</span>:<br />
* <span style="color:red">if the UE is sending a Registration Request message of type "initial registration" to a PLMN for which the UE does not already have a 5G-GUTI, the UE shall include a SUCI to the Registration Request message</span>, or<br />
* <span style="color:red">if the UE responds to an Identity Request message by which the network requests the UE to provide its permanent identifier, the UE includes a SUCI in the Identity Response message</span> as specified in clause 6.12.4. <br />
* <span style="color:red">if the UE is sending a De-Registration Request message to a PLMN during an initial registration procedure for which the UE did not receive the registration accept message with 5G-GUTI, the UE shall include the SUCI used in the initial registration to the De-Registration Request message</span>.<br />
:NOTE 3: In response to the Identity Request message, the UE never sends the SUPI.<br />
<br />
The UE shall generate a SUCI using "null-scheme" only in the following cases:<br />
* if the UE is making an unauthenticated emergency session and it does not have a 5G-GUTI to the chosen PLMN, or <br />
* if the home network has configured "null-scheme" to be used, or<br />
* if the home network has not provisioned the public key needed to generate a SUCI.<br />
<br />
If the operator's decision, indicated by the USIM, is that the USIM shall calculate the SUCI, then the USIM shall not give the ME any parameter for the calculation of the SUCI including the Home Network Public Key Identifier, the Home Network Public Key, and the Protection Scheme Identifier. If the ME determines that the calculation of the SUCI, indicated by the USIM, shall be performed by the USIM, the ME shall delete any previously received or locally cached parameters for the calculation of the SUCI including the SUPI Type, the Routing Indicator, the Home Network Public Key Identifier, the Home Network Public Key and the Protection Scheme Identifier. The operator should use proprietary identifier for protection schemes if the operator chooses that the calculation of the SUCI shall be done in USIM.<br />
<br />
If the operator's decision is that ME shall calculate the SUCI, the home network operator shall provision in the USIM an ordered priority list of the protection scheme identifiers that the operator allows. The priority list of protection scheme identifiers in the USIM shall only contain protection scheme identifiers specified in Annex C, and the list may contain one or more protection schemes identifiers. The ME shall read the SUCI calculation information from the USIM, including the SUPI, the SUPI Type, the Routing Indicator, the Home Network Public Key Identifier, the Home Network Public Key and the list of protection scheme identifiers. The ME shall select the protection scheme from its supported schemes that has the highest priority in the list are obtained from the USIM. <br />
<br />
The ME shall calculate the SUCI using the null-scheme if the Home Network Public Key or the priority list are not provisioned in the USIM.<br />
:NOTE 4: The above feature is introduced since additional protection schemes could be specified in the future for a release newer than the ME release. In this case, the protection scheme selected by older MEs may not be the protection scheme with the highest priority in the list of the USIM.<br />
<br />
=== 6.12.3 Subscription temporary identifier ===<br />
<span style="color:red">A new 5G-GUTI shall be sent to a UE only after a successful activation of NAS security</span>. The 5G-GUTI is defined in TS 23.003.<br />
<br />
<span style="color:red">Upon receiving Registration Request message of type "initial registration" or "mobility registration update" from a UE, the AMF shall send a new 5G-GUTI to the UE in the registration procedure</span>.<br />
<br />
<span style="color:red">Upon receiving Registration Request message of type "periodic registration update" from a UE, the AMF should send a new 5G-GUTI to the UE in the registration procedure</span>.<br />
<br />
<span style="color:red">Upon receiving Service Request message sent by the UE in response to a Paging message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the current NAS signalling connection is released or the N1 NAS signalling connection is suspended</span>.<br />
<br />
<span style="color:red">Upon receiving an indication from the lower layers that the RRC connection has been resumed for a UE in 5GMM-IDLE mode with suspend indication in response to a Paging message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the current NAS signalling connection is released or the suspension of the N1 NAS signalling connection</span>.<br />
:NOTE 1: It is left to implementation to re-assign 5G-GUTI more frequently than in cases mentioned above, for example after a Service Request message from the UE not triggered by the network.<br />
:NOTE 2: It is left to implementation to generate 5G-GUTI containing 5G-TMSI that uniquely identifies the UE within the AMF. <br />
<br />
5G-TMSI generation should be following the best practices of unpredictable identifier generation.<br />
<br />
A new I-RNTI shall be sent to a UE only after a successful activation of AS security.<br />
<br />
On transition of UE to RRC INACTIVE state requested by gNB during RRC Resume procedure or RNAU procedure, the gNB shall assign a new I-RNTI to the UE.<br />
<br />
=== 6.12.4 Subscription identification procedure ===<br />
<span style="color:red">The subscriber identification mechanism may be invoked by the serving network when the UE cannot be identified by means of a temporary identity (5G-GUTI)</span>. In particular, <span style="color:red">it should be used when the serving network cannot retrieve the SUPI based on the 5G-GUTI by which the subscriber identifies itself on the radio path</span>.<br />
<br />
The mechanism described in following figure allows the identification of a UE on the radio path by means of the SUCI.<br />
<br />
[[File:Subscriber identifier query.png|center]]<br />
<br />
The mechanism is initiated by the AMF that requests the UE to send its SUCI.<br />
<br />
The UE shall calculate a fresh SUCI from SUPI using the Home Network Public Key, and respond with Identity Response carrying the SUCI. The UE shall implement a mechanism to limit the frequency at which the UE responds with a fresh SUCI to an Identity Request for a given 5G-GUTI.<br />
:NOTE 1: If the UE is using any other scheme than the null-scheme, the SUCI does not reveal the SUPI.<br />
<br />
AMF may initiate authentication with AUSF to receive SUPI as specified in clause 6.1.3.<br />
<br />
In case the UE registers for Emergency Services and receives an Identity Request, the UE shall use the null-scheme for generating the SUCI in the Identity Response.<br />
:NOTE 2: Registration for Emergency does not provide subscription identifier confidentiality.<br />
<br />
=== 6.12.5 Subscription identifier de-concealing function (SIDF) ===<br />
SIDF is responsible for de-concealing the SUPI from the SUCI. When the Home Network Public Key is used for encryption of SUPI, the SIDF shall use the Home Network Private Key that is securely stored in the home operator's network to decrypt the SUCI. The de-concealment shall take place at the UDM. Access rights to the SIDF shall be defined, such that only a network element of the home network is allowed to request SIDF.<br />
:NOTE: One UDM can comprise several UDM instances. The Routing Indicator in the SUCI can be used to identify the right UDM instance that is capable of serving a subscriber.<br />
<br />
== Annex C (normative): Protection schemes for concealing the subscription permanent identifier ==<br />
<br />
=== C.2 Null-scheme ===<br />
The null-scheme shall be implemented such that it returns the same output as the input, which applies to both encryption and decryption.<br />
<br />
<span style="color:red">When using the null-scheme, the SUCI does not conceal the SUPI and therefore the newly generated SUCIs do not need to be fresh</span>.<br />
:NOTE 1: The reason for mentioning the non-freshness is that, normally, in order to attain unlinkability (i.e., to make it infeasible for over-the-air attacker to link SUCIs together), it is necessary for newly generated SUCIs to be fresh. But, in case of the null-scheme, the SUCI does not conceal the SUPI. So unlinkability is irrelevant.<br />
:NOTE 2: The null-scheme provides no privacy protection.<br />
<br />
=== C.3 Elliptic Curve Integrated Encryption Scheme (ECIES) ===<br />
<br />
==== C.3.1 General ====<br />
...<br />
Processing on UE side and home network side are described in high level in clauses C.3.2 and C.3.3.<br />
<br />
When the SUPI is of type IMSI, the subscription identifier part of the IMSI (i.e., MSIN) that is used to construct the scheme-input shall be coded as hexadecimal digits using packed BCD coding where the order of digits within an octet is same as the order of MSIN digits specified in Figure 9.11.3.4.3a of TS 24.501. If the MSIN is composed of an odd number of digits, then the bits 5 to 8 of final octet shall be coded as "1111".<br />
<br />
When the SUPI is of type network specific identifier, the subscription identifier part of the SUPI that is used to construct the scheme-input shall follow the encoding rules specified in Annex B.2.1.2 of TS 33.220.<br />
...<br />
<br />
See spec for details.<br />
<br />
== Annex F (normative): 3GPP 5G profile for EAP-AKA' ==<br />
<br />
=== F.2 Subscriber privacy ===<br />
<br />
EAP-AKA' includes optional support for identity privacy mechanism that protects the privacy against passive eavesdropping. The mechanism is described in RFC 4187 clause 4.1.1.2, and it uses pseudonyms that are delivered from the EAP server to the peer as part of an EAP-AKA exchange. The privacy mechanism described in RFC 4187 corresponds to the privacy provided by 5G-GUTI, however, assignment of 5G-GUTI is done outside the EAP framework in 5GS.<br />
<br />
<span style="color:red">TS 33.501 assumes that the SUCI is sent outside the EAP messages, however, the peer may still receive EAP-Request/Identity or EAP-Request/AKA-Identity messages</span>. Table F.2-1 specifies how the 5G UE shall behave when receiving such requests.<br />
<br />
<center>[[Telecommunications_info|To Telecommunications Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_33.501_notes&diff=3038My 3GPP 33.501 notes2023-07-16T17:00:57Z<p>Paul: /* Definitions */</p>
<hr />
<div>== § 1 Scope ==<br />
<br />
This document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.<br />
<br />
== Definitions ==<br />
=== 5G security context===<br />
The state that is established locally at the UE and a serving network domain and represented by the "5G security context data" stored at the UE and a serving network.<br />
<br />
NOTE 1: The "5G security context data" consists of the 5G NAS security context, and the 5G AS security context for 3GPP access and/or the 5G AS security context for non-3GPP access.<br />
<br />
NOTE 2: A 5G security context has type "mapped", "full native" or "partial native". Its state can either be "current" or "non-current". A context can be of one type only and be in one state at a time. The state of a particular context type can change over time. A partial native context can be transformed into a full native. No other type transformations are possible. <br />
<br />
=== 5G AS security context for 3GPP access ===<br />
The cryptographic keys at AS level with their identifiers, the Next Hop parameter (NH), the Next Hop Chaining Counter parameter (NCC) used for next hop access key derivation, the identifiers of the selected AS level cryptographic algorithms, the UE security capabilities, and the UP Security Policy at the network side, UP security activation status and the counters used for replay protection. <br />
<br />
NOTE 3: NH and NCC need to be stored also at the AMF during connected mode.<br />
<br />
NOTE 4: UP security activation status is sent from gNB/ng-eNB in step 1b in clause 6.6.2 corresponding to the active PDU session(s).<br />
<br />
=== 5G AS security context for non-3GPP access ===<br />
The key KN3IWF, the cryptographic keys, cryptographic algorithms and tunnel security association parameters used at IPsec layer for the protection of IPsec SA.<br />
<br />
=== 5G AS Secondary Cell security context ===<br />
The cryptographic keys at AS level for secondary cell with their identifiers, the identifier of the selected AS level cryptographic algorithms for secondary cell, the UP Security Policy at the network side, and counters used for replay protection.<br />
<br />
=== Home Network Public Key Identifier ===<br />
An identifier used to indicate which public/private key pair is used for SUPI protection and de-concealment of the SUCI.<br />
<br />
=== subscription credential(s) ===<br />
The set of values in the USIM and in the home operator's network, consisting of at least the long-term key(s) and the subscription identifier SUPI, used to uniquely identify a subscription and to mutually authenticate the UE and 5G core network.<br />
<br />
=== subscription identifier de-concealing function ===<br />
The Subscription Identifier De-concealing Function (SIDF) service offered by the network function UDM in the home network of the subscriber responsible for de-concealing the SUPI from the SUCI.<br />
<br />
=== UE 5G security capability ===<br />
The UE security capabilities for 5G AS and 5G NAS.<br />
<br />
=== UE security capabilities ===<br />
The set of identifiers corresponding to the ciphering and integrity algorithms implemented in the UE.<br />
<br />
NOTE 9: This includes capabilities for NG-RAN and 5G NAS, and includes capabilities for EPS, UTRAN and GERAN if these access types are supported by the UE.<br />
<br />
== Security Domains § 4.1 ==<br />
<br />
* '''Network access security (I)''': the set of security features that enable a UE to authenticate and access services via the network securely, including the 3GPP access and Non-3GPP access, and in particularly, to protect against attacks on the (radio) interfaces. In addition, it includes the security context delivery from SN to AN for the access security. <br />
* '''Network domain security (II)''': the set of security features that enable network nodes to securely exchange signalling data and user plane data. <br />
* '''User domain security (III)''': the set of security features that secure the user access to mobile equipment.<br />
* '''Application domain security (IV)''': the set of security features that enable applications in the user domain and in the provider domain to exchange messages securely. Application domain security is out of scope of the present document.<br />
* '''SBA domain security (V)''': the set of security features that enables network functions of the SBA architecture to securely communicate within the serving network domain and with other network domains . Such features include network function registration, discovery, and authorization security aspects, as well as the protection for the service-based interfaces. SBA domain security is a new security feature compared to TS 33.401.<br />
* '''Visibility and configurability of security (VI)''': the set of features that enable the user to be informed whether a security feature is in operation or not.<br />
<br />
== The 5G System architecture introduces the following security entities in the 5G Core network § 4.3 ==<br />
* AUSF: AUthentication Server Function;<br />
* ARPF: Authentication credential Repository and Processing Function;<br />
* SIDF: Subscription Identifier De-concealing Function;<br />
* SEAF: SEcurity Anchor Function.<br />
<br />
== General Security Requirements § 5.1 ==<br />
<br />
=== Mitigation of bidding down attacks § 5.1.1 ===<br />
<br />
An attacker could attempt a bidding down attack by making UE and the network entities respectively believe that the other side does not support a security feature, even when both sides support security feature. It shall be ensured that a bidding down attack, in the above sense, can be prevented.<br />
<br />
=== Authentication and Authorization § 5.1.2 ===<br />
The 5G system shall satisfy the following requirements.<br />
<br />
<span style="color:red">'''Subscription authentication</span>:''' The serving network shall authenticate the Subscription Permanent Identifier (SUPI) in the process of authentication and key agreement between UE and network.<br />
<br />
'''Serving network authentication:''' The UE shall authenticate the serving network identifier through implicit key authentication. <br />
:NOTE 1: The meaning of 'implicit key authentication' here is that authentication is provided through the successful use of keys resulting from authentication and key agreement in subsequent procedures. <br />
:NOTE 2: The preceding requirement does not imply that the UE authenticates a particular entity, e.g. an AMF, within a serving network. <br />
<br />
'''UE authorization:''' The serving network shall authorize the UE through the subscription profile obtained from the home network. UE authorization is based on the authenticated SUPI.<br />
<br />
'''Serving network authorization by the home network:''' Assurance shall be provided to the UE that it is connected to a serving network that is authorized by the home network to provide services to the UE. This authorization is 'implicit' in the sense that it is implied by a successful authentication and key agreement run.<br />
<br />
'''Access network authorization:''' Assurance shall be provided to the UE that it is connected to an access network that is authorized by the serving network to provide services to the UE. This authorization is 'implicit' in the sense that it is implied by a successful establishment of access network security. This access network authorization applies to all types of access networks.<br />
<br />
'''Unauthenticated Emergency Services:''' In order to meet regulatory requirements in some regions, the 5G system shall support unauthenticated access for emergency services. This requirement applies to all MEs and only to those serving networks where regulatory requirements for unauthenticated emergency services exist. Serving networks located in regions where unauthenticated emergency services are forbidden shall not support this feature.<br />
<br />
== Requirements of UE § 5.2 ==<br />
<br />
=== Subscriber privacy § 5.2.5 ===<br />
<br />
The UE shall support 5G Globally Unique Temporary Identifier (5G-GUTI).<br />
<br />
The SUPI '''''should not''''' be transferred in clear text over NG-RAN except routing information, e.g. Mobile Country Code (MCC) and Mobile Network Code (MNC).<br />
<br />
The Home Network Public Key shall be stored in the Universal Subscriber Identity Module (USIM). <br />
<br />
The protection scheme identifier shall be stored in the USIM.<br />
<br />
The Home Network Public Key Identifier shall be stored in the USIM.<br />
<br />
The SUCI calculation indication, either USIM or Mobile Equipment (ME) calculating the SUCI, shall be stored in USIM.<br />
<br />
<span style="color:red">The Mobile Equipment (ME) shall support the null-scheme. If the home network has not provisioned the Home Network Public Key in USIM, the SUPI protection in initial registration procedure is not provided. In this case, the null-scheme shall be used by the ME.</span><br />
<br />
Based on home operator's decision, indicated by the USIM, the calculation of the SUCI shall be performed either by the USIM or by the Mobile Equipment (ME).<br />
<br />
:NOTE 1: If the SUCI calculation indication is not present, the calculation is in the ME.<br />
<br />
<span style="color:red">In case of an unauthenticated emergency call, privacy protection for SUPI is not required</span>.<br />
<br />
Provisioning, and updating the Home Network Public Key, Home Network Public Key Identifier, protection scheme identifier, Routing Indicator, and SUCI calculation indication in the USIM shall be in the control of the home network operator. <br />
<br />
:NOTE 2: The provisioning and updating of the Home Network Public Key, Home Network Public Key Identifier, protection scheme identifier, and SUCI calculation indication is out of the scope of the present document. It can be implemented using, e.g. the Over the Air (OTA) mechanism. Routing Indicator can be updated, e.g., by OTA or as defined in clause 6.15. <br />
<br />
Subscriber privacy enablement shall be under the control of the home network of the subscriber. <br />
<br />
The UE shall only send the PEI in the NAS protocol after NAS security context is established, unless during emergency registration when no NAS security context can be established.<br />
<br />
The Routing Indicator shall be stored in the USIM. If the Routing Indicator is not present in the USIM, the ME shall set it to a default value as defined in TS 23.003.<br />
<br />
== Requirements of AMF § 5.5 ==<br />
<br />
=== Subscriber privacy § 5.5.3 ===<br />
The AMF shall support to trigger primary authentication using the SUCI.<br />
The AMF shall support assigning 5G-GUTI to the UE.<br />
The AMF shall support reallocating 5G-GUTI to UE.<br />
The AMF shall be able to confirm SUPI from UE and from home network. The AMF shall deny service to the UE if this confirmation fails.<br />
<br />
== Requirements on SEAF § 5.6 ==<br />
<br />
The security anchor function (SEAF) provides the authentication functionality via the AMF in the serving network.<br />
<br />
The SEAF shall fulfil the following requirements:<br />
* The SEAF shall support primary authentication using SUCI.<br />
<br />
== Requirements of UDM § 5.8 ==<br />
<br />
=== Subscriber privacy related requirements to UDM and SIDF § 5.8.2 ===<br />
The SIDF is responsible for de-concealment of the SUCI and shall fulfil the following requirements:<br />
* The SIDF shall be a service offered by UDM.<br />
* The SIDF shall resolve the SUPI from the SUCI based on the protection scheme used to generate the SUCI. <br />
<br />
The Home Network Private Key used for subscriber privacy shall be protected from physical attacks in the UDM. <br />
<br />
The UDM shall hold the Home Network Public Key Identifier(s) for the private/public key pair(s) used for subscriber privacy.<br />
<br />
The algorithm used for subscriber privacy shall be executed in the secure environment of the UDM.<br />
<br />
=== Requirements on AUSF § 5.8a ===<br />
The Authentication server function (AUSF) shall handle authentication requests for both, 3GPP access and non-3GPP access.<br />
<br />
The AUSF shall provide SUPI to the VPLMN only after authentication confirmation if authentication request with SUCI was sent by VPLMN.<br />
<br />
The AUSF shall inform the UDM that a successful or unsuccessful authentication of a subscriber has occurred.<br />
<br />
== Security procedures between UE and 5G network functions § 6 ==<br />
<br />
6.1 Primary authentication and key agreement<br />
<br />
6.1.1 Authentication framework<br />
<br />
=== General § 6.1.1.1 ===<br />
<br />
The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key agreement procedure results in an anchor key called the K<sub>SEAF</sub> provided by the AUSF of the home network to the SEAF of the serving network.<br />
<br />
Keys for more than one security context can be derived from the K<sub>SEAF</sub> without the need of a new authentication run. A concrete example of this is that an authentication run over a 3GPP access network can also provide keys to establish security between the UE and a N3IWF used in untrusted non-3GPP access.<br />
<br />
The anchor key K<sub>SEAF</sub> is derived from an intermediate key called the K<sub>AUSF</sub>. The K<sub>AUSF</sub> is established between the UE and HN resulting from the primary authentication procedure. The K<sub>AUSF</sub> may be securely stored in the AUSF based on the home operator's policy on using such key e.g. if the control plane solution for Steering of Roaming (see clause 6.14) or UE Parameter Update procedures (see clause 6.15) or Authentication and Key Management for Applications (AKMA) are supported by the HPLMN.<br />
<br />
NOTE A: For standalone non-public networks when an authentication method other than 5G Authentication and Key Agreement (AKA) or Extensible Authentication Protocol AKA (EAP-AKA') is used, Annex I.2 applies.<br />
<br />
NOTE 1: This feature is an optimization that might be useful, for example, when a UE registers to different serving networks for 3GPP-defined access and untrusted non-3GPP access (this is possible according to TS 23.501 [2]). The details of this feature are operator-specific and not in scope of this document.<br />
<br />
NOTE 2: A subsequent authentication based on the K<sub>AUSF</sub> stored in the AUSF gives somewhat weaker guarantees than an authentication directly involving the ARPF and the USIM. It is rather comparable to fast re-authentication in EAP-AKA'.<br />
<br />
UE and serving network shall support EAP-AKA' and 5G AKA authentication methods.<br />
<br />
NOTE 2b: It is the home operator's decision which authentication method is selected.<br />
<br />
The USIM shall reside on a UICC. The UICC may be removable or non-removable.<br />
<br />
NOTE 3: For non-3GPP access networks USIM applies in case of terminal with 3GPP access capabilities.<br />
<br />
If the terminal supports 3GPP access capabilities, the credentials used with EAP-AKA' and 5G AKA for non-3GPP access networks shall reside on the UICC.<br />
<br />
NOTE 4: EAP-AKA' and 5G AKA are the only authentication methods that are supported in UE and serving network, hence only they are described in sub-clause 6.1.3 of the present document. For a private network using the 5G system as specified in [7] an example of how additional authentication methods can be used with the EAP framework is given in the informative Annex B. <br />
<br />
NOTE 5: For non-public network (NPN) security the Annex I of the present document provides details.<br />
<br />
Upon successful completion of the 5G AKA primary authentication, the AMF shall initiate NAS security mode command procedure (see clause 6.7.2) with the UE.<br />
<br />
NOTE 6: The reason to mandatory run the NAS SMC procedure after primary authentication is because the UE does not store the new derived K<sub>AUSF</sub> until receiving the NAS SMC message. The new partial native NAS security context is taken into use. It is specified in clause 6.9.4.4 whether AS key re-keying is performed.<br />
<br />
=== EAP framework § 6.1.1.2 ===<br />
<br />
The EAP framework is specified in RFC 3748. It defines the following roles: peer, pass-through authenticator and back-end authentication server. The back-end authentication server acts as the EAP server, which terminates the EAP authentication method with the peer. In the 5G system, the EAP framework is supported in the following way:<br />
* The UE takes the role of the peer. <br />
* The SEAF takes the role of pass-through authenticator. <br />
*The AUSF takes the role of the backend authentication server.<br />
<br />
=== Construction of the serving network name § 6.1.1.4 ===<br />
<br />
See specification. Format is 5G.<SN Id> where 5G represents service code and <SN Id> is Serving Network Identifier.<br />
<br />
== 6.3 Security Contexts ==<br />
<br />
=== 6.3.2 Multiple registrations in same or different serving networks ===<br />
<br />
==== 6.3.2.0 General ====<br />
<br />
There are two cases where the UE can be multiple registered in different PLMN's serving networks or in the same PLMN's serving networks. The first case is when the UE is registered in one PLMN serving network over a certain type of access (e.g. 3GPP) and is registered to another PLMN serving network over the other type of access (e.g. non-3GPP). The second case is where the UE is registered in the same AMF in the same PLMN serving network over both 3GPP and non-3GPP accesses. The UE will establish two NAS connections with the network in both cases.<br />
:NOTE: The UE uses the same subscription credential(s) for multiple registrations in the same or different serving networks.<br />
<br />
==== 6.3.2.1 Multiple registrations in different PLMNs ====<br />
The UE shall independently maintain and use two different 5G security contexts, one per PLMN's serving network. Each security context shall be established separately via a successful primary authentication procedure with the Home PLMN.<br />
<br />
The ME shall store the two different 5G security contexts on the USIM if the USIM supports the 5G parameters storage. If the USIM does not support the 5G parameters storage, then the ME shall store the two different 5G security contexts in the ME non-volatile memory. Both of the two different 5G security contexts are current 5G security context.<br />
<br />
The latest K<sub>AUSF</sub> result of the successful completion of the latest primary authentication shall be used by the UE and the HN regardless over which access network type (3GPP or non-3GPP) it was generated.<br />
<br />
The HN shall keep the latest K<sub>AUSF</sub> generated during successful authentication over a given access even if the UE is deregistered from that access, but the UE is registered via another access.<br />
<br />
==== 6.3.2.2 Multiple registrations in the same PLMN ====<br />
<br />
When the UE is registered in the same AMF in the same PLMN serving network over both 3GPP and non-3GPP accesses, the UE shall establish two NAS connections with the network. Upon receiving the registration request message, the AMF should check whether the UE is authenticated by the network. The AMF may decide to skip a new authentication run in case there is an available 5G security context for this UE by means of 5G-GUTI, e.g. when the UE successfully registered to 3GPP access.<br />
<br />
If the UE registers to the same AMF via non-3GPP access, the AMF can decide not to run a new authentication if it has an available security context to use. In this case, the UE shall directly take into use the available common 5G NAS security context and use it to protect the registration over the non-3GPP access. If there are stored NAS counts for the non-3GPP access for the PLMN in the UE, then the stored NAS counts for the non-3GPP access for the PLMN shall be used to protect the registration over the non-3GPP access. Otherwise, the common 5G NAS security context is taken into use for the first time (partial) over non-3GPP access. In this case, the UL NAS COUNT value and DL NAS COUNT value for the non-3GPP access needs to be set to zero by the UE before the UE is taking the 5G NAS security context into use over non 3GPP access.<br />
<br />
The AMF and the UE shall establish a common NAS security context consisting of a single set of NAS keys and algorithm at the time of first registration over any access. The AMF and the UE shall also store parameters specific to each NAS connection in the common NAS security context including two pairs of NAS COUNTs for each access (i.e. 3GPP access and non-3GPP access). The connection specific parameters are specified in clause 6.4.2.2 of the present document. <br />
<br />
== 6.4 NAS security mechanisms ==<br />
<br />
=== 6.4.1 General ===<br />
<br />
This sub-clause describes the security mechanisms for the protection of NAS signalling and data between the UE and the AMF over the N1 reference point. This protection involves both integrity and confidentiality protection. The security parameters for NAS protection are part of the <span style="color:red">5G security context</span> described in sub-clause 6.3 of the present document.<br />
<br />
=== 6.4.2 Security for multiple NAS connections ===<br />
<br />
==== 6.4.2.1 Multiple active NAS connections with different PLMNs ====<br />
<br />
TS 23.501 has a scenario when the UE is registered to a VPLMN's serving network via 3GPP access and to another VPLMN's or HPLMN's serving network via non-3GPP access at the same time. When the UE is registered in one PLMN's serving network over a certain type of access (e.g. 3GPP) and is registered to another PLMN's serving network over another type of access (e.g. non-3GPP), then the UE has two active NAS connections with different AMF's in different PLMNs. As described in clause 6.3.2.1, the UE shall independently maintain and use two different 5G security contexts, one per PLMN serving network. The 5G security context maintained by the UE shall contain the full set of 5G parameters, including NAS context parameters for 3GPP and non-3GPP access types per PLMN. In case of connection to two different PLMNs, it is necessary to maintain a complete 5G NAS security context for each PLMN independently, each with all associated parameters (such as two pairs of NAS COUNTs, i.e. one pair for 3GPP access and one pair for non-3GPP access).<br />
<br />
Each security context shall be established separately via a successful primary authentication procedure with the Home PLMN. <br />
<br />
All the NAS and AS security mechanisms defined for single registration mode are applicable independently on each access using the corresponding 5G security context.<br />
<br />
:NOTE: The UE belongs to a single HPLMN.<br />
<br />
==== 6.4.2.2 Multiple active NAS connections in the same PLMN's serving network ====<br />
<br />
When the UE is registered in a serving network over two types of access (e.g. 3GPP and non-3GPP), then the UE has two active NAS connections with the same AMF. A common 5G NAS security context is created during the registration procedure over the first access type.<br />
<br />
In order to realize cryptographic separation and replay protection, the common NAS security-context shall have parameters specific to each NAS connection. The connection specific parameters include a pair of NAS COUNTs for uplink and downlink and unique NAS connection identifier. The value of the unique NAS connection identifier shall be set to "0x01" for 3GPP access and set to "0x02" for non-3GPP access. All other parameters as e.g. algorithm identifiers in the common NAS security context are common to multiple NAS connections.<br />
<br />
In non-mobility cases, when the UE is simultaneously registered over both types of accesses, and if NAS key re-keying as described in clause 6.9.4.2 or if NAS key refresh as described in clause 6.9.4.3 takes place over one of the accesses (say access A):<br />
# If the other access (access B) is in CM-CONNECTED state, then the new NAS security context shall only be activated over that access (access A). The UE and the AMF shall not change the NAS security context in use on the other access (say access B). In order to activate the new NAS security context over the other access (access B), the AMF shall trigger a NAS Security Mode Command (SMC) run over that access either in the current running procedure or a subsequent NAS procedure. During the second NAS SMC run (on access B), the AMF shall include the same ngKSI associated with the new NAS security context and the same algorithm choices as for the first access. After a successful second NAS SMC procedure over the other access (access B), both the UE and the AMF shall delete the old NAS security context.<br />
# Whenever the AMF sends a NAS SMC over access (access A) and AMF considers the UE to not be in CM-CONNECTED state on the other access (access B), the AMF shall additionally activate (if not already in use on the other access) the security context that is active on the other accesses. Similarly, whenever the UE receives a NAS SMC over the access (access A) and UE is not in CM-CONNECTED state on the other access (access B), the UE additionally activates (if not already in use on the other access) the security context on the other access.<br />
<br />
In case of 3GPP access mobility or interworking with EPS, the following procedures apply:<br />
<ol type="1"><br />
<li>If the UE is in CM-CONNECTED state on the non-3GPP access, then:</li><br />
<ol type="a"><br />
<li>if the AMF does not have the security context the UE is using on the non-3GPP access (e.g. K<sub>AMF</sub> change on 3GPP access when the AMF changes), then in order to activate the same NAS security context that is in use over the 3GPP access the AMF shall run a NAS SMC procedure on the non-3GPP access; or</li><br />
<li>in the case of handover from EPS, then a mapped context will be in use on the 3GPP access and a different security context will be active on the non-3GPP access. To align the security contexts in use over both accesses, the AMF shall run a NAS SMC procedure over one access to take into use on that access the security context that is in use on the other access. In the case that a native security context is in use on the non-3GPP access, then the NAS SMC procedure shall be on the 3GPP access to take the native security context into use.</li></ol><br />
<li>Whenever the AMF sends a Registration Accept over the 3GPP access and AMF considers the UE to not be in CM-CONNECTED state on the non-3GPP access, the AMF shall activate (if not already in use on the non-3GPP access) the security context that is in use on the 3GPP access on the non-3GPP access. The AMF shall keep a native security context that was in use on non-3GPP access if the security context in use on the 3GPP access is a mapped security context. In order to take this native security context into use, the AMF shall run a NAS SMC procedure.</li><br />
</ol><br />
:::Similarly, whenever the UE receives a Registration Accept over the 3GPP access and UE is not in CM-CONNECTED state on the non-3GPP access, the UE activates (if not already in use on the non-3GPP access) the security context that is in use on the 3GPP access on the non-3GPP access. The UE shall keep a native security context that was in use on non-3GPP access if the security context in use on the 3GPP access is a mapped security context.<br />
<br />
To recover from a failure to align the NAS security contexts due to a state mis-match between AMF and UE, the AMF can align the security contexts in use on the 3GPP and non-3GPP access using the a NAS SMC procedure during a subsequent registration procedure (that was either initiated by the UE or sent in response to a Service Reject if the UE sends a Service Request).<br />
=== 6.4.3 NAS integrity mechanisms ===<br />
<br />
See spec for details...<br />
<br />
==== 6.4.3.0 General ====<br />
Integrity protection for NAS signalling messages shall be provided as part of the NAS protocol.<br />
<br />
=== 6.4.4 NAS confidentiality mechanisms ===<br />
<br />
See spec for details...<br />
<br />
==== 6.4.4.0 General ====<br />
Confidentiality protection for NAS signalling messages shall be provided as part of the NAS protocol.<br />
<br />
==== 6.4.5 Handling of NAS COUNTs ====<br />
<br />
See spec for details...<br />
<br />
=== 6.4.6 Protection of initial NAS message ===<br />
<span style="color:red">The initial NAS message is the first NAS message that is sent after the UE transitions from the idle state</span>. The UE shall send <span style="color:red">a limited set of IEs (called the cleartext IEs) including those needed to establish security in the initial message when it has no NAS security context</span>.<br />
<br />
<span style="color:red">When the UE has a NAS security context, the UE shall send a message that has the complete initial NAS message ciphered in a NAS Container along with the cleartext IEs with whole message integrity protected.</span><br />
<br />
The complete initial message is included in the NAS Security Mode Complete (SMC) message in a NAS Container when needed (e.g. AMF cannot find the used security context) in the latter case and always in the former case as described below.<br />
<br />
:Note: See 3GPP TS 24.501 5.4.2 for Security Mode Control procedure or [[My 3GPP 24.501 notes#5.4.2 Security mode control (SMC) procedure|my security mode control notes]]<br />
<br />
In case the UE selects a PLMN other than Registered PLMN/EPLMN in the 5GMM-IDLE state and the UE has a NAS security context containing the NEA0, then the UE shall discard the NAS security context and shall follow the procedure specified in this clause for protection of initial NAS message.<br />
<br />
The protection of the initial NAS message proceeds as shown in Figure 6.4.6-1 and following.<br />
<br />
[[File:Protecting initial NAS message.png|center|Protecting initial NAS message]]<br />
<br />
Step 1: The UE shall send the initial NAS message to the AMF.<br />
* If the UE has no NAS security context, the initial NAS message shall only contain the <span style="color:red">cleartext IEs, i.e. subscription identifiers (e.g. SUCI or GUTIs)</span>, UE security capabilities, ngKSI, indication that the UE is moving from EPC, Additional GUTI, and IE containing the TAU Request in the case idle mobility from LTE.<br />
*If the UE has a NAS security context, the <span style="color:red">message sent shall contain the information given above in cleartext and the complete initial NAS message ciphered in a NAS container</span> which is ciphered. With a NAS security context, the sent message shall also be integrity protected. In the case that the initial NAS message was protected and the AMF has the same security context, then steps 2 to 4 may be omitted In this case the AMF shall use the complete initial NAS message that is in the NAS container as the message to respond to..<br />
<br />
Step 2: If the AMF is not able to find the security context locally or from last visited AMF, or if the integrity check fails, then the AMF shall initiate an authentication procedure with the UE. If the AMF fetches old security context from the last visited AMF, the AMF may decipher the NAS container with the same security context, and get the initial NAS message, then the step 2b to 4 may be omitted. If the AMF fetches new K<sub>AMF</sub> from the last visited AMF (receiving keyAmfChangeInd), the step 2b may be omitted.<br />
<br />
Step 3: If the authentication of the UE is successful, the AMF shall send the NAS Security Mode Command message. If the initial NAS message was protected but did not pass the integrity check (due either to a MAC failure or the AMF not being able to find the used security context) or the AMF could not decrypt the complete initial NAS message in the NAS container (due to receiving "keyAmfChangeInd" from the last visited AMF), then the AMF shall include in the Security Mode Command message a flag requesting the UE to send the complete initial NAS message in the NAS Security Mode Complete message. <br />
<br />
Step 4: The UE shall send the NAS Security Mode Complete message to the network in response to a NAS Security Mode Command message. The NAS Security Mode Complete message shall be ciphered and integrity protected. Furthermore the NAS Security Mode Complete message shall include the complete initial NAS message in a NAS Container if either requested by the AMF or the UE sent the initial NAS message unprotected. The AMF shall use the complete initial NAS message that is in the NAS container as the message to respond to. <br />
<br />
Step 5: <span style="color:red">The AMF shall send its response to the Initial NAS message. This message shall be '''ciphered and integrity''' protected</span>.<br />
<br />
=== 6.4.7 Security aspects of SMS over NAS ===<br />
Specific services of SMS over NAS are defined in TS 23.501, and procedures for SMS over NAS are specified in TS 23.502.<br />
<br />
For registration and de-registration procedures for SMS over NAS, the details are specified in subclause 4.13.3.1 and 4.13.3.2 in TS 23.502. The NAS message can be protected by NAS security mechanisms.<br />
<br />
For MO/MT SMS over NAS via 3GPP/non-3GPP when the UE has already activated NAS security with the AMF before sending/receiving SMS, the NAS Transport message shall be ciphered and integrity protected using the NAS security context by the UE/AMF as described in sub-clause 6.4 in the present document.<br />
<br />
== 6.5 RRC security mechanisms ==<br />
<br />
See spec for details...<br />
<br />
== 6.7 Security algorithm selection, key establishment and security mode command procedure ==<br />
<br />
=== 6.7.1 Procedures for NAS algorithm selection ===<br />
<br />
==== 6.7.1.1 Initial NAS security context establishment ====<br />
Each AMF shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered according to a priority decided by the operator.<br />
<br />
To establish the NAS security context, the AMF shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm. The AMF shall then initiate a NAS security mode command procedure, and include the chosen algorithm and UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see sub-clause 6.7.2 of the present document). The AMF shall select the NAS algorithm which have the highest priority according to the ordered lists.<br />
<br />
==== 6.7.1.2 AMF change ====<br />
If the change of the AMF at N2-Handover or mobility registration update results in the change of algorithm to be used for establishing NAS security, the target AMF shall indicate the selected algorithm to the UE as defined in Clause 6.9.2.3.3 for N2-Handover (i.e., using NAS Container) and Clause 6.9.3 for mobility registration update (i.e., using NAS SMC). The AMF shall select the NAS algorithm which has the highest priority according to the ordered lists (see sub-clause 6.7.1.1 of the present document).<br />
<br />
=== 6.7.2 NAS security mode command procedure ===<br />
<br />
See spec for details...<br />
<br />
== 6.12 Subscription identifier privacy ==<br />
<br />
=== 6.12.1 Subscription permanent identifier ===<br />
<span style="color:red">In the 5G system, the globally unique 5G subscription permanent identifier is called SUPI as defined in 3GPP TS 23.501. The SUCI is a privacy preserving identifier containing the concealed SUPI.</span><br />
<br />
<span style="color:red">The SUPI is privacy protected over-the-air by using the SUCI</span> which is described in clause 6.12.2. Handling of SUPI and privacy provisioning related to concealing the SUPI shall be done according to the requirements specified in clause 5 and details provided in clause 6.12.2.<br />
<br />
=== 6.12.2 Subscription concealed identifier ===<br />
<br />
;subscription concealed identifier: A one-time use subscription identifier, called the SUbscription Concealed Identifier (SUCI), which contains the Scheme-Output, and additional non-concealed information needed for home network routing and protection scheme usage.<br />
<br />
The SUbscription Concealed Identifier, called SUCI, is a privacy preserving identifier containing the concealed SUPI.<br />
<br />
The UE shall generate a SUCI using a protection scheme with the raw public key, i.e. the Home Network Public Key, that was securely provisioned in control of the home network. The protection schemes shall be the ones specified in Annex C of this document or the ones specified by the HPLMN.<br />
<br />
The UE shall construct a scheme-input from the subscription identifier part of the SUPI as follows:<br />
* For SUPIs containing IMSI, the subscription identifier part of the SUPI includes the MSIN of the IMSI as defined in TS 23.003. <br />
* For SUPIs taking the form of a NAI, the subscription identifier part of the SUPI includes the "username" portion of the NAI as defined in NAI RFC 7542.<br />
<br />
The UE shall execute the protection scheme with the constructed scheme-input as input and take the output as the Scheme Output.<br />
<br />
The UE shall not conceal the Home Network Identifier and the Routing Indicator.<br />
<br />
For SUPIs containing IMSI, the UE shall construct the SUCI with the following data fields:<br />
* The SUPI Type as defined in TS 23.003 identifies the type of the SUPI concealed in the SUCI.<br />
* The Home Network Identifier is set to the MCC and MNC of the IMSI as specified in 23.003.<br />
* The Routing Indicator as specified in TS 23.003.<br />
* The Protection Scheme Identifier as specified in Annex C of this specification.<br />
* The Home Network Public Key Identifier as specified in this document and detailed in TS 23.003.<br />
* The Scheme Output as specified in this document and detailed in TS 23.003.<br />
<br />
For SUPIs containing Network Specific Identifier, the UE shall construct the SUCI in NAI format with the following data fields:<br />
* realm part of the SUCI is set to the realm part of the SUPI.<br />
* username part of the SUCI is formatted as specified in TS 23.003 using the SUPI Type, Routing Indicator, the Protection Scheme Identifier, the Home Network Public Key Identifier and the Scheme Output.<br />
:NOTE 1: The format of the SUPI protection scheme identifiers is defined in Annex C. <br />
:NOTE 2: The identifier and the format of the Scheme Output are defined by the protection schemes in Annex C. In case of non-null-schemes, the freshness and randomness of the SUCI will be taken care of by the corresponding SUPI protection schemes.<br />
:NOTE 2a: In case of null-scheme being used, the Home Network Public Key Identifier is set to a default value as described in TS 23.003.<br />
<br />
<span style="color:red">The UE shall include a SUCI only in the following 5G NAS messages</span>:<br />
* <span style="color:red">if the UE is sending a Registration Request message of type "initial registration" to a PLMN for which the UE does not already have a 5G-GUTI, the UE shall include a SUCI to the Registration Request message</span>, or<br />
* <span style="color:red">if the UE responds to an Identity Request message by which the network requests the UE to provide its permanent identifier, the UE includes a SUCI in the Identity Response message</span> as specified in clause 6.12.4. <br />
* <span style="color:red">if the UE is sending a De-Registration Request message to a PLMN during an initial registration procedure for which the UE did not receive the registration accept message with 5G-GUTI, the UE shall include the SUCI used in the initial registration to the De-Registration Request message</span>.<br />
:NOTE 3: In response to the Identity Request message, the UE never sends the SUPI.<br />
<br />
The UE shall generate a SUCI using "null-scheme" only in the following cases:<br />
* if the UE is making an unauthenticated emergency session and it does not have a 5G-GUTI to the chosen PLMN, or <br />
* if the home network has configured "null-scheme" to be used, or<br />
* if the home network has not provisioned the public key needed to generate a SUCI.<br />
<br />
If the operator's decision, indicated by the USIM, is that the USIM shall calculate the SUCI, then the USIM shall not give the ME any parameter for the calculation of the SUCI including the Home Network Public Key Identifier, the Home Network Public Key, and the Protection Scheme Identifier. If the ME determines that the calculation of the SUCI, indicated by the USIM, shall be performed by the USIM, the ME shall delete any previously received or locally cached parameters for the calculation of the SUCI including the SUPI Type, the Routing Indicator, the Home Network Public Key Identifier, the Home Network Public Key and the Protection Scheme Identifier. The operator should use proprietary identifier for protection schemes if the operator chooses that the calculation of the SUCI shall be done in USIM.<br />
<br />
If the operator's decision is that ME shall calculate the SUCI, the home network operator shall provision in the USIM an ordered priority list of the protection scheme identifiers that the operator allows. The priority list of protection scheme identifiers in the USIM shall only contain protection scheme identifiers specified in Annex C, and the list may contain one or more protection schemes identifiers. The ME shall read the SUCI calculation information from the USIM, including the SUPI, the SUPI Type, the Routing Indicator, the Home Network Public Key Identifier, the Home Network Public Key and the list of protection scheme identifiers. The ME shall select the protection scheme from its supported schemes that has the highest priority in the list are obtained from the USIM. <br />
<br />
The ME shall calculate the SUCI using the null-scheme if the Home Network Public Key or the priority list are not provisioned in the USIM.<br />
:NOTE 4: The above feature is introduced since additional protection schemes could be specified in the future for a release newer than the ME release. In this case, the protection scheme selected by older MEs may not be the protection scheme with the highest priority in the list of the USIM.<br />
<br />
=== 6.12.3 Subscription temporary identifier ===<br />
<span style="color:red">A new 5G-GUTI shall be sent to a UE only after a successful activation of NAS security</span>. The 5G-GUTI is defined in TS 23.003.<br />
<br />
<span style="color:red">Upon receiving Registration Request message of type "initial registration" or "mobility registration update" from a UE, the AMF shall send a new 5G-GUTI to the UE in the registration procedure</span>.<br />
<br />
<span style="color:red">Upon receiving Registration Request message of type "periodic registration update" from a UE, the AMF should send a new 5G-GUTI to the UE in the registration procedure</span>.<br />
<br />
<span style="color:red">Upon receiving Service Request message sent by the UE in response to a Paging message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the current NAS signalling connection is released or the N1 NAS signalling connection is suspended</span>.<br />
<br />
<span style="color:red">Upon receiving an indication from the lower layers that the RRC connection has been resumed for a UE in 5GMM-IDLE mode with suspend indication in response to a Paging message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the current NAS signalling connection is released or the suspension of the N1 NAS signalling connection</span>.<br />
:NOTE 1: It is left to implementation to re-assign 5G-GUTI more frequently than in cases mentioned above, for example after a Service Request message from the UE not triggered by the network.<br />
:NOTE 2: It is left to implementation to generate 5G-GUTI containing 5G-TMSI that uniquely identifies the UE within the AMF. <br />
<br />
5G-TMSI generation should be following the best practices of unpredictable identifier generation.<br />
<br />
A new I-RNTI shall be sent to a UE only after a successful activation of AS security.<br />
<br />
On transition of UE to RRC INACTIVE state requested by gNB during RRC Resume procedure or RNAU procedure, the gNB shall assign a new I-RNTI to the UE.<br />
<br />
=== 6.12.4 Subscription identification procedure ===<br />
<span style="color:red">The subscriber identification mechanism may be invoked by the serving network when the UE cannot be identified by means of a temporary identity (5G-GUTI)</span>. In particular, <span style="color:red">it should be used when the serving network cannot retrieve the SUPI based on the 5G-GUTI by which the subscriber identifies itself on the radio path</span>.<br />
<br />
The mechanism described in following figure allows the identification of a UE on the radio path by means of the SUCI.<br />
<br />
[[File:Subscriber identifier query.png|center]]<br />
<br />
The mechanism is initiated by the AMF that requests the UE to send its SUCI.<br />
<br />
The UE shall calculate a fresh SUCI from SUPI using the Home Network Public Key, and respond with Identity Response carrying the SUCI. The UE shall implement a mechanism to limit the frequency at which the UE responds with a fresh SUCI to an Identity Request for a given 5G-GUTI.<br />
:NOTE 1: If the UE is using any other scheme than the null-scheme, the SUCI does not reveal the SUPI.<br />
<br />
AMF may initiate authentication with AUSF to receive SUPI as specified in clause 6.1.3.<br />
<br />
In case the UE registers for Emergency Services and receives an Identity Request, the UE shall use the null-scheme for generating the SUCI in the Identity Response.<br />
:NOTE 2: Registration for Emergency does not provide subscription identifier confidentiality.<br />
<br />
=== 6.12.5 Subscription identifier de-concealing function (SIDF) ===<br />
SIDF is responsible for de-concealing the SUPI from the SUCI. When the Home Network Public Key is used for encryption of SUPI, the SIDF shall use the Home Network Private Key that is securely stored in the home operator's network to decrypt the SUCI. The de-concealment shall take place at the UDM. Access rights to the SIDF shall be defined, such that only a network element of the home network is allowed to request SIDF.<br />
:NOTE: One UDM can comprise several UDM instances. The Routing Indicator in the SUCI can be used to identify the right UDM instance that is capable of serving a subscriber.<br />
<br />
== Annex C (normative): Protection schemes for concealing the subscription permanent identifier ==<br />
<br />
=== C.2 Null-scheme ===<br />
The null-scheme shall be implemented such that it returns the same output as the input, which applies to both encryption and decryption.<br />
<br />
<span style="color:red">When using the null-scheme, the SUCI does not conceal the SUPI and therefore the newly generated SUCIs do not need to be fresh</span>.<br />
:NOTE 1: The reason for mentioning the non-freshness is that, normally, in order to attain unlinkability (i.e., to make it infeasible for over-the-air attacker to link SUCIs together), it is necessary for newly generated SUCIs to be fresh. But, in case of the null-scheme, the SUCI does not conceal the SUPI. So unlinkability is irrelevant.<br />
:NOTE 2: The null-scheme provides no privacy protection.<br />
<br />
== Annex F (normative): 3GPP 5G profile for EAP-AKA' ==<br />
<br />
=== F.2 Subscriber privacy ===<br />
<br />
EAP-AKA' includes optional support for identity privacy mechanism that protects the privacy against passive eavesdropping. The mechanism is described in RFC 4187 clause 4.1.1.2, and it uses pseudonyms that are delivered from the EAP server to the peer as part of an EAP-AKA exchange. The privacy mechanism described in RFC 4187 corresponds to the privacy provided by 5G-GUTI, however, assignment of 5G-GUTI is done outside the EAP framework in 5GS.<br />
<br />
<span style="color:red">TS 33.501 assumes that the SUCI is sent outside the EAP messages, however, the peer may still receive EAP-Request/Identity or EAP-Request/AKA-Identity messages</span>. Table F.2-1 specifies how the 5G UE shall behave when receiving such requests.<br />
<br />
<center>[[Telecommunications_info|To Telecommunications Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_23.501_Notes&diff=3037My 3GPP 23.501 Notes2023-07-16T16:01:00Z<p>Paul: /* § 4.2.6 Service-based interfaces */</p>
<hr />
<div>My 3GPP 23.501 Notes<br />
<br />
== Definition and abbreviations ==<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
== § 4.2.1 General ==<br />
<br />
23.501 describes the architecture for the 5G System. The 5G architecture is defined as service-based and the interaction between network functions is represented in two ways.<br />
* A service-based representation, where network functions (e.g. AMF) within the Control Plane enables other authorized network functions to access their services. This representation also includes point-to-point reference points where necessary.<br />
* A reference point representation, shows the interaction exist between the NF services in the network functions described by point-to-point reference point (e.g. N11) between any two network functions (e.g. AMF and SMF).<br />
Service-based interfaces are listed in clause 4.2.6. Reference points are listed in clause 4.2.7.<br />
<br />
Network functions within the 5GC Control Plane shall only use service-based interfaces for their interactions.<br />
<br />
:NOTE 1: The interactions between NF services within one NF are not specified in this Release of the specification.<br />
<br />
:NOTE 2: UPF does not provide any services in this Release of the specification, but can consume services provided by 5GC Control Plane NFs.<br />
<br />
NFs and NF services can communicate directly, referred to as Direct Communication, or indirectly via the Service Communication Proxy (SCP), referred to as Indirect Communication. For more information on communication options, see Annex E and clauses under 6.3.1 and 7.1.2.<br />
<br />
In addition to the architecture descriptions in clause 4, the following areas are further described in other specifications:<br />
* NG-RAN architecture is described in TS 38.300 and TS 38.401.<br />
* Security architecture is described in TS 33.501 and TS 33.535.<br />
* Charging architecture is described in TS 32.240.<br />
* 5G Media streaming architecture is described in TS 26.501.<br />
<br />
:NOTE 3: The NFs listed in clause 4.2.2 are described in the following clauses or in the specifications above.<br />
<br />
<br />
<br />
== § 4.2.2 Network Functions and entities ==<br />
The 5G System architecture consists of the following network functions (NF):<br />
* Authentication Server Function (AUSF).<br />
* Access and Mobility Management Function (AMF).<br />
* Data Network (DN), e.g. operator services, Internet access or 3rd party services.<br />
* Unstructured Data Storage Function (UDSF).<br />
* Network Exposure Function (NEF).<br />
* Network Repository Function (NRF).<br />
* Network Slice Admission Control Function (NSACF).<br />
* Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF).<br />
* Network Slice Selection Function (NSSF).<br />
* Policy Control Function (PCF).<br />
* Session Management Function (SMF).<br />
* Unified Data Management (UDM).<br />
* Unified Data Repository (UDR).<br />
* User Plane Function (UPF).<br />
* UE radio Capability Management Function (UCMF).<br />
* Application Function (AF).<br />
* User Equipment (UE).<br />
* (Radio) Access Network ((R)AN).<br />
* 5G-Equipment Identity Register (5G-EIR).<br />
* Network Data Analytics Function (NWDAF).<br />
* CHarging Function (CHF).<br />
* Time Sensitive Networking AF (TSN AF).<br />
* Time Sensitive Communication and Time Synchronization Function (TSCTSF).<br />
* Data Collection Coordination Function (DCCF).<br />
* Analytics Data Repository Function (ADRF).<br />
* Messaging Framework Adaptor Function (MFAF).<br />
* Non-Seamless WLAN Offload Function (NSWOF).<br />
:NOTE: The functionalities provided by DCCF and/or ADRF can also be hosted by an NWDAF.<br />
* Edge Application Server Discovery Function (EASDF).<br />
<br />
The 5G System architecture also comprises the following network entities:<br />
* Service Communication Proxy (SCP).<br />
* Security Edge Protection Proxy (SEPP).<br />
<br />
The functional descriptions of these Network Functions and entities are specified in clause 6.<br />
* Non-3GPP InterWorking Function (N3IWF).<br />
* Trusted Non-3GPP Gateway Function (TNGF).<br />
* Wireline Access Gateway Function (W-AGF).<br />
* Trusted WLAN Interworking Function (TWIF).<br />
<br />
==§ 4.2.3 Non-roaming reference architecture ==<br />
<br />
See spec for diagrams and details.<br />
<br />
==§ 4.2.6 Service-based interfaces ==<br />
<br />
See spec for full list. The 5G System Architecture contains the following service-based interfaces that are of interest to me:<br />
<br />
{| class="wikitable"<br />
|+ Service-based interfaces<br />
|-<br />
! Reference !! Exhibited by !! Notes<br />
|-<br />
| Namf || AMF ||<br />
|-<br />
| Nsmf || SMF ||<br />
|-<br />
| Nudm|| UDM ||<br />
|}<br />
<br />
==§ 4.2.7 Reference Points ==<br />
<br />
The 5G System Architecture reference points:<br />
<br />
{| class="wikitable"<br />
|+ Reference Points<br />
|-<br />
! Reference !! Endpoints !! Notes<br />
|-<br />
| N1<br />
| UE and AMF<br />
|<br />
|-<br />
| N2<br />
| (R)AN and AMF<br />
|<br />
|-<br />
| N3<br />
| (R)AN and UPF<br />
|<br />
|-<br />
| N4<br />
| SMF and UPF<br />
|<br />
|-<br />
| N6<br />
| UPF and Data Network<br />
|<br />
|-<br />
| N9<br />
| UPF and UPF<br />
|<br />
|}<br />
<br />
The following reference points are of interest to me and show the interactions that exist between the NF services in the NFs. See spec for full list of reference points. These reference points are realized by corresponding NF service-based interfaces and by specifying the identified consumer and producer NF service as well as their interaction in order to realize a particular system procedure.<br />
<br />
{| class="wikitable"<br />
|+ Reference Points<br />
|-<br />
! Reference !! Endpoints !! Notes<br />
|-<br />
| N8<br />
| UDM and AMF<br />
|<br />
|-<br />
| N10<br />
| UDM and SMF<br />
|<br />
|-<br />
| N11<br />
| AMF and SMF<br />
|<br />
|-<br />
| N12<br />
| AMF and AUSF<br />
|<br />
|-<br />
| N14<br />
| AMF and AMF<br />
|<br />
|}<br />
<br />
==§ 4.2.8 Support for non-3GPP access ==<br />
<br />
=== 4.2.8.0 General ===<br />
The following types of non-3GPP access networks are defined (as of V17.5.0):<br />
* Untrusted non-3GPP access networks;<br />
* Trusted non-3GPP access networks; and<br />
* Wireline access networks.<br />
The architecture to support Untrusted and Trusted non-3GPP access networks is defined in clause 4.2.8.2. The architecture to support Wireline access networks is defined in clause 4.2.8.2.4 and in TS 23.316.<br />
<br />
== 4.2.8.1 General Concepts to Support Trusted and Untrusted Non-3GPP Access ==<br />
<br />
The 5G Core Network supports connectivity of UEs via non-3GPP access networks, e.g. WLAN access networks.<br />
<br />
Only the support of non-3GPP access networks deployed outside the NG-RAN is described in this clause.<br />
<br />
The 5G Core Network supports both untrusted non-3GPP access networks and trusted non-3GPP access networks (TNANs).<br />
<br />
An untrusted non-3GPP access network shall be connected to the 5G Core Network via a Non-3GPP InterWorking Function (N3IWF), whereas a trusted non-3GPP access network shall be connected to the 5G Core Network via a Trusted Non-3GPP Gateway Function (TNGF). Both the N3IWF and the TNGF interface with the 5G Core Network Control Plane (CP) and User Plane (UP) functions via the N2 and N3 interfaces, respectively.<br />
<br />
A non-3GPP access network may advertise the PLMNs for which it supports trusted connectivity and the type of supported trusted connectivity (e.g. "5G connectivity"). Therefore, the UEs can discover the non-3GPP access networks that can provide trusted connectivity to one or more PLMNs. This is further specified in clause 6.3.12 (Trusted Non-3GPP Access Network selection).<br />
<br />
The UE decides to use trusted or untrusted non-3GPP access for connecting to a 5G PLMN by using procedures not specified in this document. Examples of such procedures are defined in clause 6.3.12.1.<br />
<br />
When the UE decides to use untrusted non-3GPP access to connect to a 5G Core Network in a PLMN:<br />
* the UE first selects and connects with a non-3GPP access network; and then<br />
* the UE selects a PLMN and an N3IWF in this PLMN. The PLMN/N3IWF selection and the non-3GPP access network selection are independent. The N3IWF selection is defined in clause 6.3.6.<br />
<br />
When the UE decides to use trusted non-3GPP access to connect to a 5G Core Network in a PLMN:<br />
* the UE first selects a PLMN; and then<br />
* the UE selects a non-3GPP access network (a TNAN) that supports trusted connectivity to the selected PLMN. In this case, the non-3GPP access network selection is affected by the PLMN selection.<br />
<br />
<span style="color:red">A UE that accesses the 5G Core Network over a non-3GPP access shall, after UE registration, support NAS signalling with 5G Core Network control-plane functions using the N1 reference point.</span><br />
<br />
When a UE is connected via a NG-RAN and via a non-3GPP access, multiple N1 instances shall exist for the UE i.e. there shall be one N1 instance over NG-RAN and one N1 instance over non-3GPP access.<br />
<br />
A UE simultaneously connected to the same 5G Core Network of a PLMN over a 3GPP access and a non-3GPP access shall be served by a single AMF in this 5G Core Network.<br />
<br />
When a UE is connected to a 3GPP access of a PLMN, if the UE selects a N3IWF and the N3IWF is located in a PLMN different from the PLMN of the 3GPP access, e.g. in a different VPLMN or in the HPLMN, the UE is served separately by the two PLMNs. The UE is registered with two separate AMFs. PDU Sessions over the 3GPP access are served by V-SMFs different from the V-SMF serving the PDU Sessions over the non-3GPP access. The same can be true when the UE uses trusted non-3GPP access, i.e. the UE may select one PLMN for 3GPP access and a different PLMN for trusted non-3GPP access.<br />
<br />
:NOTE: The registrations with different PLMNs over different Access Types doesn't apply to UE registered for Disaster Roaming service as described in the clause 5.40.<br />
<br />
The PLMN selection for the 3GPP access does not depend on the PLMN that is used for non-3GPP access. In other words, if a UE is registered with a PLMN over a non-3GPP access, the UE performs PLMN selection for the 3GPP access independently of this PLMN.<br />
<br />
A UE shall establish an IPsec tunnel with the N3IWF or with the TNGF in order to register with the 5G Core Network over non-3GPP access. Further details about the UE registration to 5G Core Network over untrusted non-3GPP access and over trusted non-3GPP access are described in clause 4.12.2 and in clause 4.12.2a of TS 23.502, respectively.<br />
<br />
<span style="color:red">It shall be possible to maintain the UE NAS signalling connection with the AMF over the non-3GPP access after all the PDU Sessions for the UE over that access have been released or handed over to 3GPP access.</span><br />
<br />
<span style="color:red">N1 NAS signalling over non-3GPP accesses shall be protected with the same security mechanism applied for N1 over a 3GPP access.</span><br />
<br />
User plane QoS differentiation between UE and N3IWF is supported as described in clause 5.7 and clause 4.12.5 of TS 23.502. QoS differentiation between UE and TNGF is supported as described in clause 5.7 and clause 4.12a.5 of TS 23.502.<br />
<br />
== 4.3 Interworking with EPC ==<br />
<br />
=== 4.3.1 Non-roaming architecture ===<br />
<br />
See figure 4.3.1-1 in specification, it represents the non-roaming architecture for interworking between 5GS and EPC/E-UTRAN.<br />
<br />
N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core. Support of N26 interface in the network is optional for interworking. N26 supports subset of the functionalities (essential for interworking) that are supported over S10.<br />
<br />
=== 4.3.2 Roaming architecture ===<br />
<br />
See figure 4.3.2-1 in specification, it represents the Roaming architecture with local breakout and Figure 4.3.2-2 represents the Roaming architecture with home-routed traffic for interworking between 5GS and EPC/E-UTRAN.<br />
<br />
=== 4.3.3 Interworking between 5GC via non-3GPP access and E-UTRAN connected to EPC ===<br />
<br />
=== 4.3.4 Interworking between ePDG connected to EPC and 5GS ===<br />
<br />
=== 4.3.5 Service Exposure in Interworking Scenarios ===<br />
<br />
==§ 5.2.1 General==<br />
<br />
Network access is the means for user to connect to 5G Core Network (CN). Network access control comprises the following functionality:<br />
* Network selection,<br />
* Identification and authentication,<br />
* Authorization,<br />
* Access control and barring,<br />
* Policy control,<br />
* Lawful Interception.<br />
<br />
==§ 5.2.2 Network Selection==<br />
<br />
<span style="color:red">To determine which PLMN to attempt registration, UE performs network selection. The network selection procedure comprises two main parts, PLMN selection and access network (AN) selection. The requirements for PLMN selection are specified in TS 22.011 § 3.2 and the procedures are in TS 23.122.</span> The access network (AN) selection part for the 3GPP access networks is specified in TS 36.300 for E-UTRAN and in TS 38.300 for the NR. The network selection for Disaster Roaming is described in TS 23.122 and TS 24.501.<br />
<br />
==§ 5.2.3 Identification and authentication==<br />
The network may authenticate the UE during any procedure establishing a NAS signalling connection with the UE. The security architecture is specified in TS 33.501. The network may optionally perform an PEI check with 5G-EIR.<br />
<br />
==§ 5.2.4 Authorization==<br />
The authorization for connectivity of the subscriber to the 5GC and the authorization for the services that the user is allowed to access based on subscription (e.g. Operator Determined Barring, Roaming restrictions, Access Type and RAT Type currently in use) is evaluated once the user is successfully identified and authenticated. This authorization is executed during UE Registration procedure.<br />
<br />
'''§ 5.2.5 Access control and barring''' see spec<br />
<br />
==§ 5.2.6 Policy control==<br />
Network access control including service authorization may be influenced by Policy control, as specified in clause 5.14.<br />
<br />
==§ 5.2.7 Lawful Interception ==<br />
For definition and functionality of Lawful Interception, see TS 33.126.<br />
<br />
== 5.3 Registration and Connection Management ==<br />
<br />
=== 5.3.1 General ===<br />
<br />
The Registration Management is used to register or deregister a UE/user with the network (via AMF), and establish the user context in the network. The Connection Management is used to establish and release the signalling connection between the UE and the AMF.<br />
<br />
=== 5.3.2 Registration Management ===<br />
<br />
==== 5.3.2.1 General ====<br />
<br />
A UE/user needs to register with the network to receive services that requires registration. Once registered and if applicable the UE updates its registration with the network (see TS 23.502):<br />
* periodically, in order to remain reachable (Periodic Registration Update); or<br />
* upon mobility (Mobility Registration Update); or<br />
* to update its capabilities or re-negotiate protocol parameters (Mobility Registration Update).<br />
<br />
The Initial Registration procedure involves execution of Network Access Control functions as defined in clause 5.2 (i.e. user authentication and access authorization based on subscription profiles in UDM). As result of the Registration procedure, the identifier of the serving AMF serving the UE in the access through which the UE has registered will be registered in UDM.<br />
<br />
The registration management procedures are applicable over both 3GPP access and Non-3GPP access. The 3GPP and Non-3GPP RM states are independent of each other, see clause 5.3.2.4.<br />
<br />
==== 5.3.2.2 5GS Registration Management states ====<br />
<br />
===== 5.3.2.2.1 General =====<br />
<br />
Two RM states are used in the UE and the AMF that reflect the registration status of the UE in the selected PLMN:<br />
* RM-DEREGISTERED.<br />
* RM-REGISTERED.<br />
<br />
===== 5.3.2.2.2 RM-DEREGISTERED state =====<br />
<br />
In the RM DEREGISTERED state, the UE is not registered with the network. The UE context in AMF holds no valid location or routing information for the UE so the UE is not reachable by the AMF. However, some parts of UE context may still be stored in the UE and the AMF e.g. to avoid running an authentication procedure during every Registration procedure.<br />
<br />
In the RM-DEREGISTERED state, the UE shall:<br />
* attempt to register with the selected PLMN using the Initial Registration procedure if it needs to receive service that requires registration (see clause 4.2.2.2 of TS 23.502).<br />
* remain in RM-DEREGISTERED state if receiving a Registration Reject upon Initial Registration (see clause 4.2.2.2 of TS 23.502).<br />
* enter RM-REGISTERED state upon receiving a Registration Accept (see clause 4.2.2.2 of TS 23.502).<br />
<br />
When the UE RM state in the AMF is RM-DEREGISTERED, the AMF shall:<br />
* when applicable, accept the Initial Registration of a UE by sending a Registration Accept to this UE and enter RM-REGISTERED state for the UE (see clause 4.2.2.2 of TS 23.502); or<br />
* when applicable, reject the Initial Registration of a UE by sending a Registration Reject to this UE (see clause 4.2.2.2 of TS 23.502).<br />
<br />
===== 5.3.2.2.3 RM-REGISTERED state =====<br />
<br />
In the RM REGISTERED state, the UE is registered with the network. In the RM-REGISTERED state, the UE can receive services that require registration with the network.<br />
<br />
In the RM-REGISTERED state, the UE shall:<br />
* perform Mobility Registration Update procedure if the current TAI of the serving cell (see TS 37.340 [31]) is not in the list of TAIs that the UE has received from the network in order to maintain the registration and enable the AMF to page the UE;<br />
:NOTE: Additional considerations for Mobility Registration Update in case of NR satellite access are provided in clause 5.4.11.6.<br />
* perform Periodic Registration Update procedure triggered by expiration of the periodic update timer to notify the network that the UE is still active.<br />
* perform a Mobility Registration Update procedure to update its capability information or to re-negotiate protocol parameters with the network;<br />
* perform Deregistration procedure (see clause 4.2.2.3.1 of TS 23.502), and enter RM-DEREGISTERED state, when the UE needs to be no longer registered with the PLMN. The UE may decide to deregister from the network at any time.<br />
* enter RM-DEREGISTERED state when receiving a Registration Reject message or a Deregistration message. The actions of the UE depend upon the cause value' in the Registration Reject or Deregistration message. See clause 4.2.2 of TS 23.502.<br />
<br />
When the UE RM state in the AMF is RM-REGISTERED, the AMF shall:<br />
* perform Deregistration procedure (see clauses 4.2.2.3.2, 4.2.2.3.3 of TS 23.502), and enter RM-DEREGISTERED state for the UE, when the UE needs to be no longer registered with the PLMN. The network may decide to deregister the UE at any time;<br />
* perform Implicit Deregistration at any time after the Implicit Deregistration timer expires. The AMF shall enter RM-DEREGISTERED state for the UE after Implicit Deregistration;<br />
* when applicable, accept or reject Registration Requests or Service Requests from the UE.<br />
<br />
=== 5.3.3 Connection Management ===<br />
<br />
==== 5.3.3.1 General ====<br />
<br />
Connection management comprises the functions of establishing and releasing a NAS signalling connection between a UE and the AMF over N1. This NAS signalling connection is used to enable NAS signalling exchange between the UE and the core network. It comprises both the AN signalling connection between the UE and the AN (RRC Connection over 3GPP access or UE-N3IWF connection over untrusted N3GPP access or UE-TNGF connection over trusted N3GPP access) and the N2 connection for this UE between the AN and the AMF.<br />
<br />
==== 5.3.3.2 5GS Connection Management states ====<br />
<br />
===== 5.3.3.2.1 General =====<br />
Two CM states are used to reflect the NAS signalling Connection of the UE with the AMF:<br />
* CM-IDLE<br />
* CM-CONNECTED<br />
The CM state for 3GPP access and Non-3GPP access are independent of each other, i.e. one can be in CM-IDLE state at the same time when the other is in CM-CONNECTED state.<br />
<br />
==§ 5.4.7 NG-RAN location reporting==<br />
NG-RAN supports the NG-RAN location reporting for the services that require accurate cell identification (e.g. emergency services, lawful intercept, charging) or for the UE mobility event notification service subscribed to the AMF by other NFs. The NG-RAN location reporting may be used by the AMF when the target UE is in CM-CONNECTED state. The NG-RAN location reporting may be used by the AMF to determine the geographically located TAI in the case of NR satellite access.<br />
<br />
The AMF may request the NG-RAN location reporting with event reporting type (e.g. UE location or UE presence in Area of Interest), reporting mode and its related parameters (e.g. number of reporting).<br />
<br />
If the AMF requests UE location, the NG-RAN reports the current UE location (or last known UE location with time stamp if the UE is in RRC Inactive state) based on the requested reporting parameter (e.g. one-time reporting or continuous reporting).<br />
<br />
If the AMF requests UE location, in the case of NR satellite access, the NG-RAN provides all broadcast TAIs to the AMF as part of the ULI. The NG-RAN also reports the TAI where the UE is geographically located if this TAI can be determined.<br />
<br />
If the AMF requests UE presence in the Area Of Interest, the NG-RAN reports the UE location and the indication (i.e. IN, OUT or UNKNOWN) when the NG-RAN determines the change of UE presence in Area Of Interest.<br />
After N2 based Handover, if the NG-RAN location reporting information is required, the AMF shall re-request the NG-RAN location reporting to the target NG-RAN node. For Xn based Handover, the source NG-RAN shall transfer the requested NG-RAN location reporting information to target NG-RAN node.<br />
<br />
The AMF requests the location information of the UE either through independent N2 procedure (i.e. NG-RAN location reporting as specified in clause 4.10 of TS 23.502), or by including the request in some specific N2 messages as specified in TS 38.413.<br />
<br />
== 5.5 Non-3GPP access specific aspects ==<br />
<br />
=== 5.5.0 General ===<br />
This clause describe the specific aspects for untrusted non-3GPP access, trusted non-3GPP access and W-5GAN access.<br />
<br />
=== 5.5.1 Registration Management ===<br />
This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the Trusted Non-3GPP access network and to the W-5GAN (Wireline 5G Access Network). In the case of W-5GAN the UE mentioned in this clause corresponds to 5G-RG (5G Residential Gateway) or to the W-AGF (Wireline Access Gateway Function) in the case of FN-RG (Fixed Network Residential Gateway). In the case of N5CW (Non-5G-Capable over WLAN) devices access 5GC (5G Core Network) via trusted WLAN access networks, the UE mentioned in this clause corresponds to TWIF (Trusted WLAN Interworking Function).<br />
<br />
== 5.9 Identifiers ==<br />
<br />
=== 5.9.1 General ===<br />
Each subscriber in the 5G System shall be allocated one 5G Subscription Permanent Identifier (SUPI) for use within the 3GPP system. The 5G System supports identification of subscriptions independently of identification of the user equipment. Each UE accessing the 5G System shall be assigned a Permanent Equipment Identifier (PEI).<br />
<br />
The 5G System supports allocation of a temporary identifier (5G-GUTI) in order to support user confidentiality protection.<br />
<br />
=== 5.9.2 Subscription Permanent Identifier (SUPI) ===<br />
A globally unique [[My_3GPP_TS_23.003_notes#Subscription_Permanent_Identifier_.28SUPI.29_.C2.A7_2.2A|5G Subscription Permanent Identifier (SUPI)]] shall be allocated to each subscriber in the 5G System and provisioned in the UDM/UDR. The SUPI is used only inside 3GPP system, and its privacy is specified in TS 33.501.<br />
<br />
See spec for details.<br />
<br />
=== 5.9.2a Subscription Concealed Identifier (SUCI) ===<br />
The [[My_3GPP_TS_23.003_notes#Subscription_Concealed_Identifier_.28SUCI.29_.C2.A7_2.2B|Subscription Concealed Identifier (SUCI)]] is a privacy preserving identifier containing the concealed SUPI. It is specified in TS 33.501.<br />
<br />
The usage of SUCI for W-5GAN access is further specified in TS 23.316.<br />
<br />
=== 5.9.3 Permanent Equipment Identifier (PEI) ===<br />
A Permanent Equipment Identifier (PEI) is defined for the 3GPP UE accessing the 5G System.<br />
<br />
The PEI can assume different formats for different UE types and use cases. The UE shall present the PEI to the network together with an indication of the PEI format being used.<br />
<br />
If the UE supports at least one 3GPP access technology (i.e. NG-RAN, E-UTRAN, UTRAN or GERAN), the UE must be allocated a PEI in the IMEI or IMEISV format.<br />
<br />
See spec for details.<br />
<br />
=== 5.9.4 5G Globally Unique Temporary Identifier ===<br />
The AMF shall allocate a [[My_3GPP_TS_23.003_notes#Structure_of_the_5G-Short-Temporary_Mobile_Subscriber_Identity_.285G-S-TMSI.29_.C2.A7_2.11|5G Globally Unique Temporary Identifier (5G-GUTI)]] to the UE that is common to both 3GPP and non-3GPP access. It shall be possible to use the same 5G-GUTI for accessing 3GPP access and non-3GPP access security context within the AMF for the given UE. An AMF may re-assign a new 5G-GUTI to the UE at any time. The AMF provides a new 5G-GUTI to the UE under the conditions specified in clause 6.12.3 of TS 33.501. When the UE is in CM-IDLE, the AMF may delay providing the UE with a new 5G-GUTI until the next NAS transaction.<br />
<br />
The 5G-GUTI shall be structured as:<br />
<br />
<code><5G-GUTI> := <GUAMI> <5G-TMSI></code><br />
<br />
where GUAMI identifies one or more AMF(s).<br />
<br />
== 7.2 Network Function Services ==<br />
<br />
=== 7.2.2 AMF Services ===<br />
{| class="wikitable sortable"<br />
|+ NF Services provided by AMF<br />
|-<br />
! Service Name !! Description !! Reference in TS 23.502 or indicated other TS<br />
|-<br />
| Namf_Communication|| Enables an NF consumer to communicate with the UE and/or the AN through the AMF. This service enables SMF to request EBI allocation to support interworking with EPS. This service also supports PWS functionality as described in TS 23.041.|| 5.2.2.2<br />
|-<br />
| Namf_EventExposure || Enables other NF consumers to subscribe or get notified of the mobility related events and statistics. || 5.2.2.3<br />
|-<br />
| Namf_MT || Enables an NF consumer to make sure UE is reachable. || 5.2.2.4<br />
|-<br />
| Namf_Location || Enables an NF consumer to request location information for a target UE. || 5.2.2.5<br />
|-<br />
| Namf_MBSBroadcast || Enables the NF consumer to communicate with the NG-RAN for broadcast communication. || TS 23.247<br />
|-<br />
| Namf_MBSCommunication || Enables NF consumer to communicate with the NG-RAN for multicast communication. || TS 23.247<br />
|}<br />
<br />
<center>[[Telecommunications_info|To Telecommunications Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_23.501_Notes&diff=3036My 3GPP 23.501 Notes2023-07-16T15:56:18Z<p>Paul: /* 5.3.3 Connection Management */</p>
<hr />
<div>My 3GPP 23.501 Notes<br />
<br />
== Definition and abbreviations ==<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
== § 4.2.1 General ==<br />
<br />
23.501 describes the architecture for the 5G System. The 5G architecture is defined as service-based and the interaction between network functions is represented in two ways.<br />
* A service-based representation, where network functions (e.g. AMF) within the Control Plane enables other authorized network functions to access their services. This representation also includes point-to-point reference points where necessary.<br />
* A reference point representation, shows the interaction exist between the NF services in the network functions described by point-to-point reference point (e.g. N11) between any two network functions (e.g. AMF and SMF).<br />
Service-based interfaces are listed in clause 4.2.6. Reference points are listed in clause 4.2.7.<br />
<br />
Network functions within the 5GC Control Plane shall only use service-based interfaces for their interactions.<br />
<br />
:NOTE 1: The interactions between NF services within one NF are not specified in this Release of the specification.<br />
<br />
:NOTE 2: UPF does not provide any services in this Release of the specification, but can consume services provided by 5GC Control Plane NFs.<br />
<br />
NFs and NF services can communicate directly, referred to as Direct Communication, or indirectly via the Service Communication Proxy (SCP), referred to as Indirect Communication. For more information on communication options, see Annex E and clauses under 6.3.1 and 7.1.2.<br />
<br />
In addition to the architecture descriptions in clause 4, the following areas are further described in other specifications:<br />
* NG-RAN architecture is described in TS 38.300 and TS 38.401.<br />
* Security architecture is described in TS 33.501 and TS 33.535.<br />
* Charging architecture is described in TS 32.240.<br />
* 5G Media streaming architecture is described in TS 26.501.<br />
<br />
:NOTE 3: The NFs listed in clause 4.2.2 are described in the following clauses or in the specifications above.<br />
<br />
<br />
<br />
== § 4.2.2 Network Functions and entities ==<br />
The 5G System architecture consists of the following network functions (NF):<br />
* Authentication Server Function (AUSF).<br />
* Access and Mobility Management Function (AMF).<br />
* Data Network (DN), e.g. operator services, Internet access or 3rd party services.<br />
* Unstructured Data Storage Function (UDSF).<br />
* Network Exposure Function (NEF).<br />
* Network Repository Function (NRF).<br />
* Network Slice Admission Control Function (NSACF).<br />
* Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF).<br />
* Network Slice Selection Function (NSSF).<br />
* Policy Control Function (PCF).<br />
* Session Management Function (SMF).<br />
* Unified Data Management (UDM).<br />
* Unified Data Repository (UDR).<br />
* User Plane Function (UPF).<br />
* UE radio Capability Management Function (UCMF).<br />
* Application Function (AF).<br />
* User Equipment (UE).<br />
* (Radio) Access Network ((R)AN).<br />
* 5G-Equipment Identity Register (5G-EIR).<br />
* Network Data Analytics Function (NWDAF).<br />
* CHarging Function (CHF).<br />
* Time Sensitive Networking AF (TSN AF).<br />
* Time Sensitive Communication and Time Synchronization Function (TSCTSF).<br />
* Data Collection Coordination Function (DCCF).<br />
* Analytics Data Repository Function (ADRF).<br />
* Messaging Framework Adaptor Function (MFAF).<br />
* Non-Seamless WLAN Offload Function (NSWOF).<br />
:NOTE: The functionalities provided by DCCF and/or ADRF can also be hosted by an NWDAF.<br />
* Edge Application Server Discovery Function (EASDF).<br />
<br />
The 5G System architecture also comprises the following network entities:<br />
* Service Communication Proxy (SCP).<br />
* Security Edge Protection Proxy (SEPP).<br />
<br />
The functional descriptions of these Network Functions and entities are specified in clause 6.<br />
* Non-3GPP InterWorking Function (N3IWF).<br />
* Trusted Non-3GPP Gateway Function (TNGF).<br />
* Wireline Access Gateway Function (W-AGF).<br />
* Trusted WLAN Interworking Function (TWIF).<br />
<br />
==§ 4.2.6 Service-based interfaces ==<br />
<br />
See spec for full list. The 5G System Architecture contains the following service-based interfaces that are of interest to me:<br />
<br />
{| class="wikitable"<br />
|+ Service-based interfaces<br />
|-<br />
! Reference !! Exhibited by !! Notes<br />
|-<br />
| Namf || AMF ||<br />
|-<br />
| Nsmf || SMF ||<br />
|-<br />
| Nudm|| UDM ||<br />
|}<br />
<br />
==§ 4.2.7 Reference Points ==<br />
<br />
The 5G System Architecture reference points:<br />
<br />
{| class="wikitable"<br />
|+ Reference Points<br />
|-<br />
! Reference !! Endpoints !! Notes<br />
|-<br />
| N1<br />
| UE and AMF<br />
|<br />
|-<br />
| N2<br />
| (R)AN and AMF<br />
|<br />
|-<br />
| N3<br />
| (R)AN and UPF<br />
|<br />
|-<br />
| N4<br />
| SMF and UPF<br />
|<br />
|-<br />
| N6<br />
| UPF and Data Network<br />
|<br />
|-<br />
| N9<br />
| UPF and UPF<br />
|<br />
|}<br />
<br />
The following reference points are of interest to me and show the interactions that exist between the NF services in the NFs. See spec for full list of reference points. These reference points are realized by corresponding NF service-based interfaces and by specifying the identified consumer and producer NF service as well as their interaction in order to realize a particular system procedure.<br />
<br />
{| class="wikitable"<br />
|+ Reference Points<br />
|-<br />
! Reference !! Endpoints !! Notes<br />
|-<br />
| N8<br />
| UDM and AMF<br />
|<br />
|-<br />
| N10<br />
| UDM and SMF<br />
|<br />
|-<br />
| N11<br />
| AMF and SMF<br />
|<br />
|-<br />
| N12<br />
| AMF and AUSF<br />
|<br />
|-<br />
| N14<br />
| AMF and AMF<br />
|<br />
|}<br />
<br />
==§ 4.2.8 Support for non-3GPP access ==<br />
<br />
=== 4.2.8.0 General ===<br />
The following types of non-3GPP access networks are defined (as of V17.5.0):<br />
* Untrusted non-3GPP access networks;<br />
* Trusted non-3GPP access networks; and<br />
* Wireline access networks.<br />
The architecture to support Untrusted and Trusted non-3GPP access networks is defined in clause 4.2.8.2. The architecture to support Wireline access networks is defined in clause 4.2.8.2.4 and in TS 23.316.<br />
<br />
== 4.2.8.1 General Concepts to Support Trusted and Untrusted Non-3GPP Access ==<br />
<br />
The 5G Core Network supports connectivity of UEs via non-3GPP access networks, e.g. WLAN access networks.<br />
<br />
Only the support of non-3GPP access networks deployed outside the NG-RAN is described in this clause.<br />
<br />
The 5G Core Network supports both untrusted non-3GPP access networks and trusted non-3GPP access networks (TNANs).<br />
<br />
An untrusted non-3GPP access network shall be connected to the 5G Core Network via a Non-3GPP InterWorking Function (N3IWF), whereas a trusted non-3GPP access network shall be connected to the 5G Core Network via a Trusted Non-3GPP Gateway Function (TNGF). Both the N3IWF and the TNGF interface with the 5G Core Network Control Plane (CP) and User Plane (UP) functions via the N2 and N3 interfaces, respectively.<br />
<br />
A non-3GPP access network may advertise the PLMNs for which it supports trusted connectivity and the type of supported trusted connectivity (e.g. "5G connectivity"). Therefore, the UEs can discover the non-3GPP access networks that can provide trusted connectivity to one or more PLMNs. This is further specified in clause 6.3.12 (Trusted Non-3GPP Access Network selection).<br />
<br />
The UE decides to use trusted or untrusted non-3GPP access for connecting to a 5G PLMN by using procedures not specified in this document. Examples of such procedures are defined in clause 6.3.12.1.<br />
<br />
When the UE decides to use untrusted non-3GPP access to connect to a 5G Core Network in a PLMN:<br />
* the UE first selects and connects with a non-3GPP access network; and then<br />
* the UE selects a PLMN and an N3IWF in this PLMN. The PLMN/N3IWF selection and the non-3GPP access network selection are independent. The N3IWF selection is defined in clause 6.3.6.<br />
<br />
When the UE decides to use trusted non-3GPP access to connect to a 5G Core Network in a PLMN:<br />
* the UE first selects a PLMN; and then<br />
* the UE selects a non-3GPP access network (a TNAN) that supports trusted connectivity to the selected PLMN. In this case, the non-3GPP access network selection is affected by the PLMN selection.<br />
<br />
<span style="color:red">A UE that accesses the 5G Core Network over a non-3GPP access shall, after UE registration, support NAS signalling with 5G Core Network control-plane functions using the N1 reference point.</span><br />
<br />
When a UE is connected via a NG-RAN and via a non-3GPP access, multiple N1 instances shall exist for the UE i.e. there shall be one N1 instance over NG-RAN and one N1 instance over non-3GPP access.<br />
<br />
A UE simultaneously connected to the same 5G Core Network of a PLMN over a 3GPP access and a non-3GPP access shall be served by a single AMF in this 5G Core Network.<br />
<br />
When a UE is connected to a 3GPP access of a PLMN, if the UE selects a N3IWF and the N3IWF is located in a PLMN different from the PLMN of the 3GPP access, e.g. in a different VPLMN or in the HPLMN, the UE is served separately by the two PLMNs. The UE is registered with two separate AMFs. PDU Sessions over the 3GPP access are served by V-SMFs different from the V-SMF serving the PDU Sessions over the non-3GPP access. The same can be true when the UE uses trusted non-3GPP access, i.e. the UE may select one PLMN for 3GPP access and a different PLMN for trusted non-3GPP access.<br />
<br />
:NOTE: The registrations with different PLMNs over different Access Types doesn't apply to UE registered for Disaster Roaming service as described in the clause 5.40.<br />
<br />
The PLMN selection for the 3GPP access does not depend on the PLMN that is used for non-3GPP access. In other words, if a UE is registered with a PLMN over a non-3GPP access, the UE performs PLMN selection for the 3GPP access independently of this PLMN.<br />
<br />
A UE shall establish an IPsec tunnel with the N3IWF or with the TNGF in order to register with the 5G Core Network over non-3GPP access. Further details about the UE registration to 5G Core Network over untrusted non-3GPP access and over trusted non-3GPP access are described in clause 4.12.2 and in clause 4.12.2a of TS 23.502, respectively.<br />
<br />
<span style="color:red">It shall be possible to maintain the UE NAS signalling connection with the AMF over the non-3GPP access after all the PDU Sessions for the UE over that access have been released or handed over to 3GPP access.</span><br />
<br />
<span style="color:red">N1 NAS signalling over non-3GPP accesses shall be protected with the same security mechanism applied for N1 over a 3GPP access.</span><br />
<br />
User plane QoS differentiation between UE and N3IWF is supported as described in clause 5.7 and clause 4.12.5 of TS 23.502. QoS differentiation between UE and TNGF is supported as described in clause 5.7 and clause 4.12a.5 of TS 23.502.<br />
<br />
== 4.3 Interworking with EPC ==<br />
<br />
=== 4.3.1 Non-roaming architecture ===<br />
<br />
See figure 4.3.1-1 in specification, it represents the non-roaming architecture for interworking between 5GS and EPC/E-UTRAN.<br />
<br />
N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core. Support of N26 interface in the network is optional for interworking. N26 supports subset of the functionalities (essential for interworking) that are supported over S10.<br />
<br />
=== 4.3.2 Roaming architecture ===<br />
<br />
See figure 4.3.2-1 in specification, it represents the Roaming architecture with local breakout and Figure 4.3.2-2 represents the Roaming architecture with home-routed traffic for interworking between 5GS and EPC/E-UTRAN.<br />
<br />
=== 4.3.3 Interworking between 5GC via non-3GPP access and E-UTRAN connected to EPC ===<br />
<br />
=== 4.3.4 Interworking between ePDG connected to EPC and 5GS ===<br />
<br />
=== 4.3.5 Service Exposure in Interworking Scenarios ===<br />
<br />
==§ 5.2.1 General==<br />
<br />
Network access is the means for user to connect to 5G Core Network (CN). Network access control comprises the following functionality:<br />
* Network selection,<br />
* Identification and authentication,<br />
* Authorization,<br />
* Access control and barring,<br />
* Policy control,<br />
* Lawful Interception.<br />
<br />
==§ 5.2.2 Network Selection==<br />
<br />
<span style="color:red">To determine which PLMN to attempt registration, UE performs network selection. The network selection procedure comprises two main parts, PLMN selection and access network (AN) selection. The requirements for PLMN selection are specified in TS 22.011 § 3.2 and the procedures are in TS 23.122.</span> The access network (AN) selection part for the 3GPP access networks is specified in TS 36.300 for E-UTRAN and in TS 38.300 for the NR. The network selection for Disaster Roaming is described in TS 23.122 and TS 24.501.<br />
<br />
==§ 5.2.3 Identification and authentication==<br />
The network may authenticate the UE during any procedure establishing a NAS signalling connection with the UE. The security architecture is specified in TS 33.501. The network may optionally perform an PEI check with 5G-EIR.<br />
<br />
==§ 5.2.4 Authorization==<br />
The authorization for connectivity of the subscriber to the 5GC and the authorization for the services that the user is allowed to access based on subscription (e.g. Operator Determined Barring, Roaming restrictions, Access Type and RAT Type currently in use) is evaluated once the user is successfully identified and authenticated. This authorization is executed during UE Registration procedure.<br />
<br />
'''§ 5.2.5 Access control and barring''' see spec<br />
<br />
==§ 5.2.6 Policy control==<br />
Network access control including service authorization may be influenced by Policy control, as specified in clause 5.14.<br />
<br />
==§ 5.2.7 Lawful Interception ==<br />
For definition and functionality of Lawful Interception, see TS 33.126.<br />
<br />
== 5.3 Registration and Connection Management ==<br />
<br />
=== 5.3.1 General ===<br />
<br />
The Registration Management is used to register or deregister a UE/user with the network (via AMF), and establish the user context in the network. The Connection Management is used to establish and release the signalling connection between the UE and the AMF.<br />
<br />
=== 5.3.2 Registration Management ===<br />
<br />
==== 5.3.2.1 General ====<br />
<br />
A UE/user needs to register with the network to receive services that requires registration. Once registered and if applicable the UE updates its registration with the network (see TS 23.502):<br />
* periodically, in order to remain reachable (Periodic Registration Update); or<br />
* upon mobility (Mobility Registration Update); or<br />
* to update its capabilities or re-negotiate protocol parameters (Mobility Registration Update).<br />
<br />
The Initial Registration procedure involves execution of Network Access Control functions as defined in clause 5.2 (i.e. user authentication and access authorization based on subscription profiles in UDM). As result of the Registration procedure, the identifier of the serving AMF serving the UE in the access through which the UE has registered will be registered in UDM.<br />
<br />
The registration management procedures are applicable over both 3GPP access and Non-3GPP access. The 3GPP and Non-3GPP RM states are independent of each other, see clause 5.3.2.4.<br />
<br />
==== 5.3.2.2 5GS Registration Management states ====<br />
<br />
===== 5.3.2.2.1 General =====<br />
<br />
Two RM states are used in the UE and the AMF that reflect the registration status of the UE in the selected PLMN:<br />
* RM-DEREGISTERED.<br />
* RM-REGISTERED.<br />
<br />
===== 5.3.2.2.2 RM-DEREGISTERED state =====<br />
<br />
In the RM DEREGISTERED state, the UE is not registered with the network. The UE context in AMF holds no valid location or routing information for the UE so the UE is not reachable by the AMF. However, some parts of UE context may still be stored in the UE and the AMF e.g. to avoid running an authentication procedure during every Registration procedure.<br />
<br />
In the RM-DEREGISTERED state, the UE shall:<br />
* attempt to register with the selected PLMN using the Initial Registration procedure if it needs to receive service that requires registration (see clause 4.2.2.2 of TS 23.502).<br />
* remain in RM-DEREGISTERED state if receiving a Registration Reject upon Initial Registration (see clause 4.2.2.2 of TS 23.502).<br />
* enter RM-REGISTERED state upon receiving a Registration Accept (see clause 4.2.2.2 of TS 23.502).<br />
<br />
When the UE RM state in the AMF is RM-DEREGISTERED, the AMF shall:<br />
* when applicable, accept the Initial Registration of a UE by sending a Registration Accept to this UE and enter RM-REGISTERED state for the UE (see clause 4.2.2.2 of TS 23.502); or<br />
* when applicable, reject the Initial Registration of a UE by sending a Registration Reject to this UE (see clause 4.2.2.2 of TS 23.502).<br />
<br />
===== 5.3.2.2.3 RM-REGISTERED state =====<br />
<br />
In the RM REGISTERED state, the UE is registered with the network. In the RM-REGISTERED state, the UE can receive services that require registration with the network.<br />
<br />
In the RM-REGISTERED state, the UE shall:<br />
* perform Mobility Registration Update procedure if the current TAI of the serving cell (see TS 37.340 [31]) is not in the list of TAIs that the UE has received from the network in order to maintain the registration and enable the AMF to page the UE;<br />
:NOTE: Additional considerations for Mobility Registration Update in case of NR satellite access are provided in clause 5.4.11.6.<br />
* perform Periodic Registration Update procedure triggered by expiration of the periodic update timer to notify the network that the UE is still active.<br />
* perform a Mobility Registration Update procedure to update its capability information or to re-negotiate protocol parameters with the network;<br />
* perform Deregistration procedure (see clause 4.2.2.3.1 of TS 23.502), and enter RM-DEREGISTERED state, when the UE needs to be no longer registered with the PLMN. The UE may decide to deregister from the network at any time.<br />
* enter RM-DEREGISTERED state when receiving a Registration Reject message or a Deregistration message. The actions of the UE depend upon the cause value' in the Registration Reject or Deregistration message. See clause 4.2.2 of TS 23.502.<br />
<br />
When the UE RM state in the AMF is RM-REGISTERED, the AMF shall:<br />
* perform Deregistration procedure (see clauses 4.2.2.3.2, 4.2.2.3.3 of TS 23.502), and enter RM-DEREGISTERED state for the UE, when the UE needs to be no longer registered with the PLMN. The network may decide to deregister the UE at any time;<br />
* perform Implicit Deregistration at any time after the Implicit Deregistration timer expires. The AMF shall enter RM-DEREGISTERED state for the UE after Implicit Deregistration;<br />
* when applicable, accept or reject Registration Requests or Service Requests from the UE.<br />
<br />
=== 5.3.3 Connection Management ===<br />
<br />
==== 5.3.3.1 General ====<br />
<br />
Connection management comprises the functions of establishing and releasing a NAS signalling connection between a UE and the AMF over N1. This NAS signalling connection is used to enable NAS signalling exchange between the UE and the core network. It comprises both the AN signalling connection between the UE and the AN (RRC Connection over 3GPP access or UE-N3IWF connection over untrusted N3GPP access or UE-TNGF connection over trusted N3GPP access) and the N2 connection for this UE between the AN and the AMF.<br />
<br />
==== 5.3.3.2 5GS Connection Management states ====<br />
<br />
===== 5.3.3.2.1 General =====<br />
Two CM states are used to reflect the NAS signalling Connection of the UE with the AMF:<br />
* CM-IDLE<br />
* CM-CONNECTED<br />
The CM state for 3GPP access and Non-3GPP access are independent of each other, i.e. one can be in CM-IDLE state at the same time when the other is in CM-CONNECTED state.<br />
<br />
==§ 5.4.7 NG-RAN location reporting==<br />
NG-RAN supports the NG-RAN location reporting for the services that require accurate cell identification (e.g. emergency services, lawful intercept, charging) or for the UE mobility event notification service subscribed to the AMF by other NFs. The NG-RAN location reporting may be used by the AMF when the target UE is in CM-CONNECTED state. The NG-RAN location reporting may be used by the AMF to determine the geographically located TAI in the case of NR satellite access.<br />
<br />
The AMF may request the NG-RAN location reporting with event reporting type (e.g. UE location or UE presence in Area of Interest), reporting mode and its related parameters (e.g. number of reporting).<br />
<br />
If the AMF requests UE location, the NG-RAN reports the current UE location (or last known UE location with time stamp if the UE is in RRC Inactive state) based on the requested reporting parameter (e.g. one-time reporting or continuous reporting).<br />
<br />
If the AMF requests UE location, in the case of NR satellite access, the NG-RAN provides all broadcast TAIs to the AMF as part of the ULI. The NG-RAN also reports the TAI where the UE is geographically located if this TAI can be determined.<br />
<br />
If the AMF requests UE presence in the Area Of Interest, the NG-RAN reports the UE location and the indication (i.e. IN, OUT or UNKNOWN) when the NG-RAN determines the change of UE presence in Area Of Interest.<br />
After N2 based Handover, if the NG-RAN location reporting information is required, the AMF shall re-request the NG-RAN location reporting to the target NG-RAN node. For Xn based Handover, the source NG-RAN shall transfer the requested NG-RAN location reporting information to target NG-RAN node.<br />
<br />
The AMF requests the location information of the UE either through independent N2 procedure (i.e. NG-RAN location reporting as specified in clause 4.10 of TS 23.502), or by including the request in some specific N2 messages as specified in TS 38.413.<br />
<br />
== 5.5 Non-3GPP access specific aspects ==<br />
<br />
=== 5.5.0 General ===<br />
This clause describe the specific aspects for untrusted non-3GPP access, trusted non-3GPP access and W-5GAN access.<br />
<br />
=== 5.5.1 Registration Management ===<br />
This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the Trusted Non-3GPP access network and to the W-5GAN (Wireline 5G Access Network). In the case of W-5GAN the UE mentioned in this clause corresponds to 5G-RG (5G Residential Gateway) or to the W-AGF (Wireline Access Gateway Function) in the case of FN-RG (Fixed Network Residential Gateway). In the case of N5CW (Non-5G-Capable over WLAN) devices access 5GC (5G Core Network) via trusted WLAN access networks, the UE mentioned in this clause corresponds to TWIF (Trusted WLAN Interworking Function).<br />
<br />
== 5.9 Identifiers ==<br />
<br />
=== 5.9.1 General ===<br />
Each subscriber in the 5G System shall be allocated one 5G Subscription Permanent Identifier (SUPI) for use within the 3GPP system. The 5G System supports identification of subscriptions independently of identification of the user equipment. Each UE accessing the 5G System shall be assigned a Permanent Equipment Identifier (PEI).<br />
<br />
The 5G System supports allocation of a temporary identifier (5G-GUTI) in order to support user confidentiality protection.<br />
<br />
=== 5.9.2 Subscription Permanent Identifier (SUPI) ===<br />
A globally unique [[My_3GPP_TS_23.003_notes#Subscription_Permanent_Identifier_.28SUPI.29_.C2.A7_2.2A|5G Subscription Permanent Identifier (SUPI)]] shall be allocated to each subscriber in the 5G System and provisioned in the UDM/UDR. The SUPI is used only inside 3GPP system, and its privacy is specified in TS 33.501.<br />
<br />
See spec for details.<br />
<br />
=== 5.9.2a Subscription Concealed Identifier (SUCI) ===<br />
The [[My_3GPP_TS_23.003_notes#Subscription_Concealed_Identifier_.28SUCI.29_.C2.A7_2.2B|Subscription Concealed Identifier (SUCI)]] is a privacy preserving identifier containing the concealed SUPI. It is specified in TS 33.501.<br />
<br />
The usage of SUCI for W-5GAN access is further specified in TS 23.316.<br />
<br />
=== 5.9.3 Permanent Equipment Identifier (PEI) ===<br />
A Permanent Equipment Identifier (PEI) is defined for the 3GPP UE accessing the 5G System.<br />
<br />
The PEI can assume different formats for different UE types and use cases. The UE shall present the PEI to the network together with an indication of the PEI format being used.<br />
<br />
If the UE supports at least one 3GPP access technology (i.e. NG-RAN, E-UTRAN, UTRAN or GERAN), the UE must be allocated a PEI in the IMEI or IMEISV format.<br />
<br />
See spec for details.<br />
<br />
=== 5.9.4 5G Globally Unique Temporary Identifier ===<br />
The AMF shall allocate a [[My_3GPP_TS_23.003_notes#Structure_of_the_5G-Short-Temporary_Mobile_Subscriber_Identity_.285G-S-TMSI.29_.C2.A7_2.11|5G Globally Unique Temporary Identifier (5G-GUTI)]] to the UE that is common to both 3GPP and non-3GPP access. It shall be possible to use the same 5G-GUTI for accessing 3GPP access and non-3GPP access security context within the AMF for the given UE. An AMF may re-assign a new 5G-GUTI to the UE at any time. The AMF provides a new 5G-GUTI to the UE under the conditions specified in clause 6.12.3 of TS 33.501. When the UE is in CM-IDLE, the AMF may delay providing the UE with a new 5G-GUTI until the next NAS transaction.<br />
<br />
The 5G-GUTI shall be structured as:<br />
<br />
<code><5G-GUTI> := <GUAMI> <5G-TMSI></code><br />
<br />
where GUAMI identifies one or more AMF(s).<br />
<br />
== 7.2 Network Function Services ==<br />
<br />
=== 7.2.2 AMF Services ===<br />
{| class="wikitable sortable"<br />
|+ NF Services provided by AMF<br />
|-<br />
! Service Name !! Description !! Reference in TS 23.502 or indicated other TS<br />
|-<br />
| Namf_Communication|| Enables an NF consumer to communicate with the UE and/or the AN through the AMF. This service enables SMF to request EBI allocation to support interworking with EPS. This service also supports PWS functionality as described in TS 23.041.|| 5.2.2.2<br />
|-<br />
| Namf_EventExposure || Enables other NF consumers to subscribe or get notified of the mobility related events and statistics. || 5.2.2.3<br />
|-<br />
| Namf_MT || Enables an NF consumer to make sure UE is reachable. || 5.2.2.4<br />
|-<br />
| Namf_Location || Enables an NF consumer to request location information for a target UE. || 5.2.2.5<br />
|-<br />
| Namf_MBSBroadcast || Enables the NF consumer to communicate with the NG-RAN for broadcast communication. || TS 23.247<br />
|-<br />
| Namf_MBSCommunication || Enables NF consumer to communicate with the NG-RAN for multicast communication. || TS 23.247<br />
|}<br />
<br />
<center>[[Telecommunications_info|To Telecommunications Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_23.501_Notes&diff=3035My 3GPP 23.501 Notes2023-07-16T15:53:44Z<p>Paul: /* 5.3.2.2.3 RM-REGISTERED state */</p>
<hr />
<div>My 3GPP 23.501 Notes<br />
<br />
== Definition and abbreviations ==<br />
<br />
See [[My 3GPP definition notes]] for definitions<br />
<br />
See [[My 3GPP abbreviation notes]] for abbreviations<br />
<br />
== § 4.2.1 General ==<br />
<br />
23.501 describes the architecture for the 5G System. The 5G architecture is defined as service-based and the interaction between network functions is represented in two ways.<br />
* A service-based representation, where network functions (e.g. AMF) within the Control Plane enables other authorized network functions to access their services. This representation also includes point-to-point reference points where necessary.<br />
* A reference point representation, shows the interaction exist between the NF services in the network functions described by point-to-point reference point (e.g. N11) between any two network functions (e.g. AMF and SMF).<br />
Service-based interfaces are listed in clause 4.2.6. Reference points are listed in clause 4.2.7.<br />
<br />
Network functions within the 5GC Control Plane shall only use service-based interfaces for their interactions.<br />
<br />
:NOTE 1: The interactions between NF services within one NF are not specified in this Release of the specification.<br />
<br />
:NOTE 2: UPF does not provide any services in this Release of the specification, but can consume services provided by 5GC Control Plane NFs.<br />
<br />
NFs and NF services can communicate directly, referred to as Direct Communication, or indirectly via the Service Communication Proxy (SCP), referred to as Indirect Communication. For more information on communication options, see Annex E and clauses under 6.3.1 and 7.1.2.<br />
<br />
In addition to the architecture descriptions in clause 4, the following areas are further described in other specifications:<br />
* NG-RAN architecture is described in TS 38.300 and TS 38.401.<br />
* Security architecture is described in TS 33.501 and TS 33.535.<br />
* Charging architecture is described in TS 32.240.<br />
* 5G Media streaming architecture is described in TS 26.501.<br />
<br />
:NOTE 3: The NFs listed in clause 4.2.2 are described in the following clauses or in the specifications above.<br />
<br />
<br />
<br />
== § 4.2.2 Network Functions and entities ==<br />
The 5G System architecture consists of the following network functions (NF):<br />
* Authentication Server Function (AUSF).<br />
* Access and Mobility Management Function (AMF).<br />
* Data Network (DN), e.g. operator services, Internet access or 3rd party services.<br />
* Unstructured Data Storage Function (UDSF).<br />
* Network Exposure Function (NEF).<br />
* Network Repository Function (NRF).<br />
* Network Slice Admission Control Function (NSACF).<br />
* Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF).<br />
* Network Slice Selection Function (NSSF).<br />
* Policy Control Function (PCF).<br />
* Session Management Function (SMF).<br />
* Unified Data Management (UDM).<br />
* Unified Data Repository (UDR).<br />
* User Plane Function (UPF).<br />
* UE radio Capability Management Function (UCMF).<br />
* Application Function (AF).<br />
* User Equipment (UE).<br />
* (Radio) Access Network ((R)AN).<br />
* 5G-Equipment Identity Register (5G-EIR).<br />
* Network Data Analytics Function (NWDAF).<br />
* CHarging Function (CHF).<br />
* Time Sensitive Networking AF (TSN AF).<br />
* Time Sensitive Communication and Time Synchronization Function (TSCTSF).<br />
* Data Collection Coordination Function (DCCF).<br />
* Analytics Data Repository Function (ADRF).<br />
* Messaging Framework Adaptor Function (MFAF).<br />
* Non-Seamless WLAN Offload Function (NSWOF).<br />
:NOTE: The functionalities provided by DCCF and/or ADRF can also be hosted by an NWDAF.<br />
* Edge Application Server Discovery Function (EASDF).<br />
<br />
The 5G System architecture also comprises the following network entities:<br />
* Service Communication Proxy (SCP).<br />
* Security Edge Protection Proxy (SEPP).<br />
<br />
The functional descriptions of these Network Functions and entities are specified in clause 6.<br />
* Non-3GPP InterWorking Function (N3IWF).<br />
* Trusted Non-3GPP Gateway Function (TNGF).<br />
* Wireline Access Gateway Function (W-AGF).<br />
* Trusted WLAN Interworking Function (TWIF).<br />
<br />
==§ 4.2.6 Service-based interfaces ==<br />
<br />
See spec for full list. The 5G System Architecture contains the following service-based interfaces that are of interest to me:<br />
<br />
{| class="wikitable"<br />
|+ Service-based interfaces<br />
|-<br />
! Reference !! Exhibited by !! Notes<br />
|-<br />
| Namf || AMF ||<br />
|-<br />
| Nsmf || SMF ||<br />
|-<br />
| Nudm|| UDM ||<br />
|}<br />
<br />
==§ 4.2.7 Reference Points ==<br />
<br />
The 5G System Architecture reference points:<br />
<br />
{| class="wikitable"<br />
|+ Reference Points<br />
|-<br />
! Reference !! Endpoints !! Notes<br />
|-<br />
| N1<br />
| UE and AMF<br />
|<br />
|-<br />
| N2<br />
| (R)AN and AMF<br />
|<br />
|-<br />
| N3<br />
| (R)AN and UPF<br />
|<br />
|-<br />
| N4<br />
| SMF and UPF<br />
|<br />
|-<br />
| N6<br />
| UPF and Data Network<br />
|<br />
|-<br />
| N9<br />
| UPF and UPF<br />
|<br />
|}<br />
<br />
The following reference points are of interest to me and show the interactions that exist between the NF services in the NFs. See spec for full list of reference points. These reference points are realized by corresponding NF service-based interfaces and by specifying the identified consumer and producer NF service as well as their interaction in order to realize a particular system procedure.<br />
<br />
{| class="wikitable"<br />
|+ Reference Points<br />
|-<br />
! Reference !! Endpoints !! Notes<br />
|-<br />
| N8<br />
| UDM and AMF<br />
|<br />
|-<br />
| N10<br />
| UDM and SMF<br />
|<br />
|-<br />
| N11<br />
| AMF and SMF<br />
|<br />
|-<br />
| N12<br />
| AMF and AUSF<br />
|<br />
|-<br />
| N14<br />
| AMF and AMF<br />
|<br />
|}<br />
<br />
==§ 4.2.8 Support for non-3GPP access ==<br />
<br />
=== 4.2.8.0 General ===<br />
The following types of non-3GPP access networks are defined (as of V17.5.0):<br />
* Untrusted non-3GPP access networks;<br />
* Trusted non-3GPP access networks; and<br />
* Wireline access networks.<br />
The architecture to support Untrusted and Trusted non-3GPP access networks is defined in clause 4.2.8.2. The architecture to support Wireline access networks is defined in clause 4.2.8.2.4 and in TS 23.316.<br />
<br />
== 4.2.8.1 General Concepts to Support Trusted and Untrusted Non-3GPP Access ==<br />
<br />
The 5G Core Network supports connectivity of UEs via non-3GPP access networks, e.g. WLAN access networks.<br />
<br />
Only the support of non-3GPP access networks deployed outside the NG-RAN is described in this clause.<br />
<br />
The 5G Core Network supports both untrusted non-3GPP access networks and trusted non-3GPP access networks (TNANs).<br />
<br />
An untrusted non-3GPP access network shall be connected to the 5G Core Network via a Non-3GPP InterWorking Function (N3IWF), whereas a trusted non-3GPP access network shall be connected to the 5G Core Network via a Trusted Non-3GPP Gateway Function (TNGF). Both the N3IWF and the TNGF interface with the 5G Core Network Control Plane (CP) and User Plane (UP) functions via the N2 and N3 interfaces, respectively.<br />
<br />
A non-3GPP access network may advertise the PLMNs for which it supports trusted connectivity and the type of supported trusted connectivity (e.g. "5G connectivity"). Therefore, the UEs can discover the non-3GPP access networks that can provide trusted connectivity to one or more PLMNs. This is further specified in clause 6.3.12 (Trusted Non-3GPP Access Network selection).<br />
<br />
The UE decides to use trusted or untrusted non-3GPP access for connecting to a 5G PLMN by using procedures not specified in this document. Examples of such procedures are defined in clause 6.3.12.1.<br />
<br />
When the UE decides to use untrusted non-3GPP access to connect to a 5G Core Network in a PLMN:<br />
* the UE first selects and connects with a non-3GPP access network; and then<br />
* the UE selects a PLMN and an N3IWF in this PLMN. The PLMN/N3IWF selection and the non-3GPP access network selection are independent. The N3IWF selection is defined in clause 6.3.6.<br />
<br />
When the UE decides to use trusted non-3GPP access to connect to a 5G Core Network in a PLMN:<br />
* the UE first selects a PLMN; and then<br />
* the UE selects a non-3GPP access network (a TNAN) that supports trusted connectivity to the selected PLMN. In this case, the non-3GPP access network selection is affected by the PLMN selection.<br />
<br />
<span style="color:red">A UE that accesses the 5G Core Network over a non-3GPP access shall, after UE registration, support NAS signalling with 5G Core Network control-plane functions using the N1 reference point.</span><br />
<br />
When a UE is connected via a NG-RAN and via a non-3GPP access, multiple N1 instances shall exist for the UE i.e. there shall be one N1 instance over NG-RAN and one N1 instance over non-3GPP access.<br />
<br />
A UE simultaneously connected to the same 5G Core Network of a PLMN over a 3GPP access and a non-3GPP access shall be served by a single AMF in this 5G Core Network.<br />
<br />
When a UE is connected to a 3GPP access of a PLMN, if the UE selects a N3IWF and the N3IWF is located in a PLMN different from the PLMN of the 3GPP access, e.g. in a different VPLMN or in the HPLMN, the UE is served separately by the two PLMNs. The UE is registered with two separate AMFs. PDU Sessions over the 3GPP access are served by V-SMFs different from the V-SMF serving the PDU Sessions over the non-3GPP access. The same can be true when the UE uses trusted non-3GPP access, i.e. the UE may select one PLMN for 3GPP access and a different PLMN for trusted non-3GPP access.<br />
<br />
:NOTE: The registrations with different PLMNs over different Access Types doesn't apply to UE registered for Disaster Roaming service as described in the clause 5.40.<br />
<br />
The PLMN selection for the 3GPP access does not depend on the PLMN that is used for non-3GPP access. In other words, if a UE is registered with a PLMN over a non-3GPP access, the UE performs PLMN selection for the 3GPP access independently of this PLMN.<br />
<br />
A UE shall establish an IPsec tunnel with the N3IWF or with the TNGF in order to register with the 5G Core Network over non-3GPP access. Further details about the UE registration to 5G Core Network over untrusted non-3GPP access and over trusted non-3GPP access are described in clause 4.12.2 and in clause 4.12.2a of TS 23.502, respectively.<br />
<br />
<span style="color:red">It shall be possible to maintain the UE NAS signalling connection with the AMF over the non-3GPP access after all the PDU Sessions for the UE over that access have been released or handed over to 3GPP access.</span><br />
<br />
<span style="color:red">N1 NAS signalling over non-3GPP accesses shall be protected with the same security mechanism applied for N1 over a 3GPP access.</span><br />
<br />
User plane QoS differentiation between UE and N3IWF is supported as described in clause 5.7 and clause 4.12.5 of TS 23.502. QoS differentiation between UE and TNGF is supported as described in clause 5.7 and clause 4.12a.5 of TS 23.502.<br />
<br />
== 4.3 Interworking with EPC ==<br />
<br />
=== 4.3.1 Non-roaming architecture ===<br />
<br />
See figure 4.3.1-1 in specification, it represents the non-roaming architecture for interworking between 5GS and EPC/E-UTRAN.<br />
<br />
N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core. Support of N26 interface in the network is optional for interworking. N26 supports subset of the functionalities (essential for interworking) that are supported over S10.<br />
<br />
=== 4.3.2 Roaming architecture ===<br />
<br />
See figure 4.3.2-1 in specification, it represents the Roaming architecture with local breakout and Figure 4.3.2-2 represents the Roaming architecture with home-routed traffic for interworking between 5GS and EPC/E-UTRAN.<br />
<br />
=== 4.3.3 Interworking between 5GC via non-3GPP access and E-UTRAN connected to EPC ===<br />
<br />
=== 4.3.4 Interworking between ePDG connected to EPC and 5GS ===<br />
<br />
=== 4.3.5 Service Exposure in Interworking Scenarios ===<br />
<br />
==§ 5.2.1 General==<br />
<br />
Network access is the means for user to connect to 5G Core Network (CN). Network access control comprises the following functionality:<br />
* Network selection,<br />
* Identification and authentication,<br />
* Authorization,<br />
* Access control and barring,<br />
* Policy control,<br />
* Lawful Interception.<br />
<br />
==§ 5.2.2 Network Selection==<br />
<br />
<span style="color:red">To determine which PLMN to attempt registration, UE performs network selection. The network selection procedure comprises two main parts, PLMN selection and access network (AN) selection. The requirements for PLMN selection are specified in TS 22.011 § 3.2 and the procedures are in TS 23.122.</span> The access network (AN) selection part for the 3GPP access networks is specified in TS 36.300 for E-UTRAN and in TS 38.300 for the NR. The network selection for Disaster Roaming is described in TS 23.122 and TS 24.501.<br />
<br />
==§ 5.2.3 Identification and authentication==<br />
The network may authenticate the UE during any procedure establishing a NAS signalling connection with the UE. The security architecture is specified in TS 33.501. The network may optionally perform an PEI check with 5G-EIR.<br />
<br />
==§ 5.2.4 Authorization==<br />
The authorization for connectivity of the subscriber to the 5GC and the authorization for the services that the user is allowed to access based on subscription (e.g. Operator Determined Barring, Roaming restrictions, Access Type and RAT Type currently in use) is evaluated once the user is successfully identified and authenticated. This authorization is executed during UE Registration procedure.<br />
<br />
'''§ 5.2.5 Access control and barring''' see spec<br />
<br />
==§ 5.2.6 Policy control==<br />
Network access control including service authorization may be influenced by Policy control, as specified in clause 5.14.<br />
<br />
==§ 5.2.7 Lawful Interception ==<br />
For definition and functionality of Lawful Interception, see TS 33.126.<br />
<br />
== 5.3 Registration and Connection Management ==<br />
<br />
=== 5.3.1 General ===<br />
<br />
The Registration Management is used to register or deregister a UE/user with the network (via AMF), and establish the user context in the network. The Connection Management is used to establish and release the signalling connection between the UE and the AMF.<br />
<br />
=== 5.3.2 Registration Management ===<br />
<br />
==== 5.3.2.1 General ====<br />
<br />
A UE/user needs to register with the network to receive services that requires registration. Once registered and if applicable the UE updates its registration with the network (see TS 23.502):<br />
* periodically, in order to remain reachable (Periodic Registration Update); or<br />
* upon mobility (Mobility Registration Update); or<br />
* to update its capabilities or re-negotiate protocol parameters (Mobility Registration Update).<br />
<br />
The Initial Registration procedure involves execution of Network Access Control functions as defined in clause 5.2 (i.e. user authentication and access authorization based on subscription profiles in UDM). As result of the Registration procedure, the identifier of the serving AMF serving the UE in the access through which the UE has registered will be registered in UDM.<br />
<br />
The registration management procedures are applicable over both 3GPP access and Non-3GPP access. The 3GPP and Non-3GPP RM states are independent of each other, see clause 5.3.2.4.<br />
<br />
==== 5.3.2.2 5GS Registration Management states ====<br />
<br />
===== 5.3.2.2.1 General =====<br />
<br />
Two RM states are used in the UE and the AMF that reflect the registration status of the UE in the selected PLMN:<br />
* RM-DEREGISTERED.<br />
* RM-REGISTERED.<br />
<br />
===== 5.3.2.2.2 RM-DEREGISTERED state =====<br />
<br />
In the RM DEREGISTERED state, the UE is not registered with the network. The UE context in AMF holds no valid location or routing information for the UE so the UE is not reachable by the AMF. However, some parts of UE context may still be stored in the UE and the AMF e.g. to avoid running an authentication procedure during every Registration procedure.<br />
<br />
In the RM-DEREGISTERED state, the UE shall:<br />
* attempt to register with the selected PLMN using the Initial Registration procedure if it needs to receive service that requires registration (see clause 4.2.2.2 of TS 23.502).<br />
* remain in RM-DEREGISTERED state if receiving a Registration Reject upon Initial Registration (see clause 4.2.2.2 of TS 23.502).<br />
* enter RM-REGISTERED state upon receiving a Registration Accept (see clause 4.2.2.2 of TS 23.502).<br />
<br />
When the UE RM state in the AMF is RM-DEREGISTERED, the AMF shall:<br />
* when applicable, accept the Initial Registration of a UE by sending a Registration Accept to this UE and enter RM-REGISTERED state for the UE (see clause 4.2.2.2 of TS 23.502); or<br />
* when applicable, reject the Initial Registration of a UE by sending a Registration Reject to this UE (see clause 4.2.2.2 of TS 23.502).<br />
<br />
===== 5.3.2.2.3 RM-REGISTERED state =====<br />
<br />
In the RM REGISTERED state, the UE is registered with the network. In the RM-REGISTERED state, the UE can receive services that require registration with the network.<br />
<br />
In the RM-REGISTERED state, the UE shall:<br />
* perform Mobility Registration Update procedure if the current TAI of the serving cell (see TS 37.340 [31]) is not in the list of TAIs that the UE has received from the network in order to maintain the registration and enable the AMF to page the UE;<br />
:NOTE: Additional considerations for Mobility Registration Update in case of NR satellite access are provided in clause 5.4.11.6.<br />
* perform Periodic Registration Update procedure triggered by expiration of the periodic update timer to notify the network that the UE is still active.<br />
* perform a Mobility Registration Update procedure to update its capability information or to re-negotiate protocol parameters with the network;<br />
* perform Deregistration procedure (see clause 4.2.2.3.1 of TS 23.502), and enter RM-DEREGISTERED state, when the UE needs to be no longer registered with the PLMN. The UE may decide to deregister from the network at any time.<br />
* enter RM-DEREGISTERED state when receiving a Registration Reject message or a Deregistration message. The actions of the UE depend upon the cause value' in the Registration Reject or Deregistration message. See clause 4.2.2 of TS 23.502.<br />
<br />
When the UE RM state in the AMF is RM-REGISTERED, the AMF shall:<br />
* perform Deregistration procedure (see clauses 4.2.2.3.2, 4.2.2.3.3 of TS 23.502), and enter RM-DEREGISTERED state for the UE, when the UE needs to be no longer registered with the PLMN. The network may decide to deregister the UE at any time;<br />
* perform Implicit Deregistration at any time after the Implicit Deregistration timer expires. The AMF shall enter RM-DEREGISTERED state for the UE after Implicit Deregistration;<br />
* when applicable, accept or reject Registration Requests or Service Requests from the UE.<br />
<br />
=== 5.3.3 Connection Management ===<br />
<br />
==§ 5.4.7 NG-RAN location reporting==<br />
NG-RAN supports the NG-RAN location reporting for the services that require accurate cell identification (e.g. emergency services, lawful intercept, charging) or for the UE mobility event notification service subscribed to the AMF by other NFs. The NG-RAN location reporting may be used by the AMF when the target UE is in CM-CONNECTED state. The NG-RAN location reporting may be used by the AMF to determine the geographically located TAI in the case of NR satellite access.<br />
<br />
The AMF may request the NG-RAN location reporting with event reporting type (e.g. UE location or UE presence in Area of Interest), reporting mode and its related parameters (e.g. number of reporting).<br />
<br />
If the AMF requests UE location, the NG-RAN reports the current UE location (or last known UE location with time stamp if the UE is in RRC Inactive state) based on the requested reporting parameter (e.g. one-time reporting or continuous reporting).<br />
<br />
If the AMF requests UE location, in the case of NR satellite access, the NG-RAN provides all broadcast TAIs to the AMF as part of the ULI. The NG-RAN also reports the TAI where the UE is geographically located if this TAI can be determined.<br />
<br />
If the AMF requests UE presence in the Area Of Interest, the NG-RAN reports the UE location and the indication (i.e. IN, OUT or UNKNOWN) when the NG-RAN determines the change of UE presence in Area Of Interest.<br />
After N2 based Handover, if the NG-RAN location reporting information is required, the AMF shall re-request the NG-RAN location reporting to the target NG-RAN node. For Xn based Handover, the source NG-RAN shall transfer the requested NG-RAN location reporting information to target NG-RAN node.<br />
<br />
The AMF requests the location information of the UE either through independent N2 procedure (i.e. NG-RAN location reporting as specified in clause 4.10 of TS 23.502), or by including the request in some specific N2 messages as specified in TS 38.413.<br />
<br />
== 5.5 Non-3GPP access specific aspects ==<br />
<br />
=== 5.5.0 General ===<br />
This clause describe the specific aspects for untrusted non-3GPP access, trusted non-3GPP access and W-5GAN access.<br />
<br />
=== 5.5.1 Registration Management ===<br />
This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the Trusted Non-3GPP access network and to the W-5GAN (Wireline 5G Access Network). In the case of W-5GAN the UE mentioned in this clause corresponds to 5G-RG (5G Residential Gateway) or to the W-AGF (Wireline Access Gateway Function) in the case of FN-RG (Fixed Network Residential Gateway). In the case of N5CW (Non-5G-Capable over WLAN) devices access 5GC (5G Core Network) via trusted WLAN access networks, the UE mentioned in this clause corresponds to TWIF (Trusted WLAN Interworking Function).<br />
<br />
== 5.9 Identifiers ==<br />
<br />
=== 5.9.1 General ===<br />
Each subscriber in the 5G System shall be allocated one 5G Subscription Permanent Identifier (SUPI) for use within the 3GPP system. The 5G System supports identification of subscriptions independently of identification of the user equipment. Each UE accessing the 5G System shall be assigned a Permanent Equipment Identifier (PEI).<br />
<br />
The 5G System supports allocation of a temporary identifier (5G-GUTI) in order to support user confidentiality protection.<br />
<br />
=== 5.9.2 Subscription Permanent Identifier (SUPI) ===<br />
A globally unique [[My_3GPP_TS_23.003_notes#Subscription_Permanent_Identifier_.28SUPI.29_.C2.A7_2.2A|5G Subscription Permanent Identifier (SUPI)]] shall be allocated to each subscriber in the 5G System and provisioned in the UDM/UDR. The SUPI is used only inside 3GPP system, and its privacy is specified in TS 33.501.<br />
<br />
See spec for details.<br />
<br />
=== 5.9.2a Subscription Concealed Identifier (SUCI) ===<br />
The [[My_3GPP_TS_23.003_notes#Subscription_Concealed_Identifier_.28SUCI.29_.C2.A7_2.2B|Subscription Concealed Identifier (SUCI)]] is a privacy preserving identifier containing the concealed SUPI. It is specified in TS 33.501.<br />
<br />
The usage of SUCI for W-5GAN access is further specified in TS 23.316.<br />
<br />
=== 5.9.3 Permanent Equipment Identifier (PEI) ===<br />
A Permanent Equipment Identifier (PEI) is defined for the 3GPP UE accessing the 5G System.<br />
<br />
The PEI can assume different formats for different UE types and use cases. The UE shall present the PEI to the network together with an indication of the PEI format being used.<br />
<br />
If the UE supports at least one 3GPP access technology (i.e. NG-RAN, E-UTRAN, UTRAN or GERAN), the UE must be allocated a PEI in the IMEI or IMEISV format.<br />
<br />
See spec for details.<br />
<br />
=== 5.9.4 5G Globally Unique Temporary Identifier ===<br />
The AMF shall allocate a [[My_3GPP_TS_23.003_notes#Structure_of_the_5G-Short-Temporary_Mobile_Subscriber_Identity_.285G-S-TMSI.29_.C2.A7_2.11|5G Globally Unique Temporary Identifier (5G-GUTI)]] to the UE that is common to both 3GPP and non-3GPP access. It shall be possible to use the same 5G-GUTI for accessing 3GPP access and non-3GPP access security context within the AMF for the given UE. An AMF may re-assign a new 5G-GUTI to the UE at any time. The AMF provides a new 5G-GUTI to the UE under the conditions specified in clause 6.12.3 of TS 33.501. When the UE is in CM-IDLE, the AMF may delay providing the UE with a new 5G-GUTI until the next NAS transaction.<br />
<br />
The 5G-GUTI shall be structured as:<br />
<br />
<code><5G-GUTI> := <GUAMI> <5G-TMSI></code><br />
<br />
where GUAMI identifies one or more AMF(s).<br />
<br />
== 7.2 Network Function Services ==<br />
<br />
=== 7.2.2 AMF Services ===<br />
{| class="wikitable sortable"<br />
|+ NF Services provided by AMF<br />
|-<br />
! Service Name !! Description !! Reference in TS 23.502 or indicated other TS<br />
|-<br />
| Namf_Communication|| Enables an NF consumer to communicate with the UE and/or the AN through the AMF. This service enables SMF to request EBI allocation to support interworking with EPS. This service also supports PWS functionality as described in TS 23.041.|| 5.2.2.2<br />
|-<br />
| Namf_EventExposure || Enables other NF consumers to subscribe or get notified of the mobility related events and statistics. || 5.2.2.3<br />
|-<br />
| Namf_MT || Enables an NF consumer to make sure UE is reachable. || 5.2.2.4<br />
|-<br />
| Namf_Location || Enables an NF consumer to request location information for a target UE. || 5.2.2.5<br />
|-<br />
| Namf_MBSBroadcast || Enables the NF consumer to communicate with the NG-RAN for broadcast communication. || TS 23.247<br />
|-<br />
| Namf_MBSCommunication || Enables NF consumer to communicate with the NG-RAN for multicast communication. || TS 23.247<br />
|}<br />
<br />
<center>[[Telecommunications_info|To Telecommunications Info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_24.501_notes&diff=3034My 3GPP 24.501 notes2023-07-16T15:24:35Z<p>Paul: /* 4.4.1 General */</p>
<hr />
<div>== 1 Scope ==<br />
3GPP TS 24.501 document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
The 5GS session management (5GSM) protocol defined in the present document provides procedures for the handling of 5GS PDU sessions. Together with the bearer control provided by the access stratum, this protocol is used for the control of user-plane resources.<br />
<br />
For both NAS protocols the present document specifies procedures for the support of inter-system mobility between the NG-RAN and the evolved universal terrestrial radio access (E-UTRAN), between the NG-RAN and the non-3GPP access network connected to the EPC, and between the non-3GPP access network connected to the 5G core network (5GCN) and the E-UTRAN.<br />
<br />
For both NAS protocols the present document specifies procedures for the support of mobility between the NG-RAN and the non-3GPP access network connected to the 5GCN.<br />
<br />
In addition, the present document specifies the procedures in the 5GS for UE policy delivery service between the UE and the policy control function (PCF) for both 3GPP access and non-3GPP access.<br />
<br />
The present document is applicable to the UE, the access and mobility management function (AMF), the session management function (SMF), and the PCF in the 5GS.<br />
<br />
The clauses and subclauses in the present document are common for both 3GPP access and non-3GPP access unless it is explicitly stated that they apply to 3GPP access only or non-3GPP access only.<br />
<br />
== 4.1 Overview ==<br />
The <span style="color:red">non-access stratum (NAS) described in 24.501 forms the highest stratum of the control plane between UE and AMF</span> (reference point "N1" see 3GPP TS 23.501) for both 3GPP and non-3GPP access.<br />
<br />
Main functions of the protocols that are part of the NAS are:<br />
* support of mobility of the user equipment (UE) including also common procedures such as authentication, identification, generic UE configuration update and security mode control procedures;<br />
* support of session management procedures to establish and maintain data connectivity between the UE and the data network; and<br />
* NAS transport procedure to provide a transport of SMS, LPP, LCS, UE policy container, SOR transparent container and UE parameters update information payload.<br />
<br />
Principles for the handing of 5GS security contexts and for the activation of ciphering and integrity protection, when a NAS signalling connection is established, are provided in subclause 4.4.<br />
<br />
For the support of the above functions, the following procedures are supplied within this specification:<br />
* elementary procedures for 5GS mobility management in clause 5; and<br />
* elementary procedures for 5GS session management in clause 6.<br />
<br />
Signalling procedures for the control of NAS security are described as part of the 5GMM common procedures in subclause 5.4.<br />
<br />
Complete NAS transactions consist of specific sequences of elementary procedures. Examples of such specific sequences can be found in 3GPP TS 23.502.<br />
<br />
The NAS for 5GS follows the protocol architecture model for layer 3 as described in 3GPP TS 24.007.<br />
<br />
== 4.2 Coordination between the protocols for 5GS mobility management and 5GS session management ==<br />
A 5G system (5GS) session management (5GSM) message is piggybacked in specific 5GS mobility management (5GMM) transport messages. To this purpose, the 5GSM messages can be transmitted in an information element in the 5GMM transport messages. In this case, the UE, the AMF and the SMF execute the 5GMM procedure and the 5GSM procedure in parallel. The success of the 5GMM procedure is not dependent on the success of the piggybacked 5GSM procedure.<br />
<br />
<span style="color:red">The UE can only initiate the 5GSM procedure when there is a 5GMM context established at the UE.</span><br />
<br />
During 5GMM procedures, the UE and the AMF shall suspend the transmission of 5GSM messages, except when:<br />
<ol type="a"><br />
<li>the 5GMM procedure is piggybacking 5GSM messages; or</li><br />
<li>the UE is in 5GMM-CONNECTED mode and a service request procedure for re-establishing user-plane resources of PDU session(s) is initiated without including PDU session status IE or Allowed PDU session status IE. In this case, the UE and the AMF need not suspend the transmission of 5GSM messages related to other PDU session(s) than the one(s) for which the user- plane resources re-establishment is requested.</li><br />
</ol><br />
<br />
If the UE determines to locally release the N1 NAS signalling connection upon receiving an Steering of Roaming (SOR) transparent container during a registration procedure as specified in 3GPP TS 23.122 Annex C.2, the UE shall suspend the transmission of 5GSM messages after sending the REGISTRATION COMPLETE message and until the N1 NAS signalling connection is released to obtain service on a higher priority PLMN, with the exception of the case when the UE has an emergency PDU session.<br />
<br />
A 5GMM message piggybacking a 5GSM message for a PDU session shall be delivered via the access associated with the PDU session, if any, with the following exceptions:<br />
<ol type="a"><br />
<li>the AMF shall send, via 3GPP access, a Downlink (DL) NAS TRANSPORT message piggybacking a downlink 5GSM message of a network-requested 5GSM procedure for a PDU session associated with non-3GPP access if the conditions specified in subclause 5.5.1.3.4 or subclause 5.6.1.4 are met;</li><br />
<li>the UE shall send an UL NAS TRANSPORT message piggybacking a response message to the 5GSM message described in a) via either:</li><br />
# 3GPP access; or<br />
# non-3GPP access if the UE is in 5GMM-CONNECTED mode over non-3GPP access; and<br />
:NOTE: The interaction between the 5GMM sublayer and the 5GSM sublayer to enable the UE to send the UL NAS TRANSPORT message containing the response message via 3GPP access is required. This is achieved via UE implementation.<br />
<li>the UE shall send, via the target access, an Uplink (UL) NAS TRANSPORT message piggybacking a 5GSM message associated with a request type set to "existing PDU session" or "existing emergency PDU session" for handover of an existing PDU session between 3GPP access and non-3GPP access.</li><br />
</ol><br />
<br />
A 5GMM message piggybacking a 5GSM message as a response message to a request message associated with an MA PDU session, shall be delivered via the same access that the initial message was received.<br />
<br />
== UE domain selection ==<br />
<br />
See spec<br />
<br />
== 4.4 NAS security ==<br />
<br />
=== 4.4.1 General ===<br />
This clause describes the principles for the handling of 5G NAS security contexts in the UE and in the AMF, the procedures used for the <span style="color:blue">security protection of NAS messages between the UE and the AMF</span>, and the procedures used for the <span style="color:blue">protection of NAS IEs between the UE and the UDM</span>. <span style="color:purple">Security protection involves integrity protection and ciphering of the 5GMM messages. 5GSM messages are security protected indirectly by being piggybacked by the security protected 5GMM messages (i.e. UL NAS TRANSPORT message and the DL NAS TRANSPORT message)</span>.<br />
<br />
The signalling procedures for the control of NAS security are part of the 5GMM protocol and are described in detail in clause 5.<br />
<br />
<span style="color:green">NOTE ''The use of ciphering in a network is an operator option.'' In this subclause, for the ease of description, it is assumed that ciphering is used, unless explicitly indicated otherwise. Operation of a network without ciphering is achieved by configuring the AMF so that it always selects the "null ciphering algorithm", 5G-EA0.</span><br />
<br />
=== 4.4.2 Handling of 5G NAS security contexts ===<br />
<br />
==== 4.4.2.5 Establishment of secure exchange of NAS messages ====<br />
Secure exchange of NAS messages via a NAS signalling connection is <span style="color:red">usually established by the AMF during the registration procedure by initiating a security mode control procedure</span>. After successful completion of the security mode control procedure, all NAS messages exchanged between the UE and the AMF are sent integrity protected using the current 5G security algorithms, and <span style="color:red">except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered</span> using the current 5G security algorithms.<br />
<br />
==== 4.4.4.2 Integrity checking of NAS signalling messages in the UE ====<br />
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the UE or forwarded to the 5GSM entity, unless the network has established secure exchange of 5GS NAS messages for the NAS signalling connection:<br />
<ol type="a"><br />
<li>IDENTITY REQUEST (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION REQUEST;</li><br />
<li>AUTHENTICATION RESULT;</li><br />
<li>AUTHENTICATION REJECT;</li><br />
<li>REGISTRATION REJECT (if the 5GMM cause is not #76 or #78);</li><br />
<li>DEREGISTRATION ACCEPT (for non switch off); and</li><br />
<li>SERVICE REJECT (if the 5GMM cause is not #76 or #78).</li><br />
</ol><br />
:NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.<br />
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once the secure exchange of NAS messages has been established, the receiving 5GMM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. The processing of the SECURITY MODE COMMAND message that has not successfully passed the integrity check is specified in subclause 5.4.2.5. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.<br />
<br />
==== 4.4.4.3 Integrity checking of NAS signalling messages in the AMF ====<br />
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the AMF or forwarded to the 5GSM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:<br />
<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST;</li><br />
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION RESPONSE;</li><br />
<li>AUTHENTICATION FAILURE;</li><br />
<li>SECURITY MODE REJECT;</li><br />
<li>DEREGISTRATION REQUEST; and</li><br />
<li>DEREGISTRATION ACCEPT;</li><br />
</ol><br />
<br />
:NOTE 1: The REGISTRATION REQUEST message is sent by the UE without integrity protection, if the registration procedure is initiated due to an inter-system change in 5GMM-IDLE mode and no current 5G NAS security context is available in the UE. The other messages are accepted by the AMF without integrity protection, as in certain situations they are sent by the UE before security can be activated.<br />
<br />
:NOTE 2: The DEREGISTRATION REQUEST message can be sent by the UE without integrity protection, e.g. if the UE is registered for emergency services and there is no valid 5G NAS security context available, or if due to user interaction a registration procedure is cancelled before the secure exchange of NAS messages has been established. For these cases the network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.<br />
<br />
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once a current 5G NAS security context exists, until the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF shall process the following NAS signalling messages, even if the MAC included in the message fails the integrity check or cannot be verified, as the 5G NAS security context is not available in the network:<br />
<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST;</li><br />
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION RESPONSE;</li><br />
<li>AUTHENTICATION FAILURE;</li><br />
<li>SECURITY MODE REJECT;</li><br />
<li>DEREGISTRATION REQUEST;</li><br />
<li>DEREGISTRATION ACCEPT;</li><br />
<li>SERVICE REQUEST; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST;</li><br />
</ol><br />
<br />
:NOTE 3: These messages are processed by the AMF even when the MAC that fails the integrity check or cannot be verified, as in certain situations they can be sent by the UE protected with a 5G NAS security context that is no longer available in the network.<br />
<br />
If a REGISTRATION REQUEST message for initial registration fails the integrity check and it is not a registration request for emergency services, the AMF shall authenticate the subscriber before processing the registration request any further. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the registration procedure is for emergency services see subclause 5.5.1.2.3 and subclause 5.4.1.3.5.<br />
<br />
If a REGISTRATION REQUEST message for mobility and periodic registration update fails the integrity check and the UE provided EPS NAS message container IE which was successfully verified by the source MME, the AMF may create a mapped 5G NAS security context and initiate a security mode control procedure to take the new mapped 5G NAS security context into use; otherwise if the UE has only a non-emergency PDU session established, the AMF shall initiate a primary authentication and key agreement procedure to create a new native 5G NAS security context. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the UE has an emergency PDU session see subclause 5.5.1.3.3 and subclause 5.4.1.3.5.<br />
<br />
If a DEREGISTRATION REQUEST message fails the integrity check, the AMF shall proceed as follows:<br />
:- If it is not a deregistration request due to switch off, and the AMF can initiate an authentication procedure, the AMF should authenticate the subscriber before processing the deregistration request any further.<br />
:- If it is a deregistration request due to switch off, or the AMF does not initiate an authentication procedure for any other reason, the AMF may ignore the deregistration request and remain in state 5GMM-REGISTERED.<br />
:NOTE 4: The network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.<br />
<br />
If a SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message fails the integrity check and the UE has only non-emergency PDU sessions established, the AMF shall send the SERVICE REJECT message with 5GMM cause #9 "UE identity cannot be derived by the network" and keep the 5GMM-context and 5G NAS security context unchanged. For the case when the UE has an emergency PDU session and integrity check fails, the AMF may skip the authentication procedure even if no 5G NAS security context is available and proceed directly to the execution of the security mode control procedure as specified in subclause 5.4.2. Additionally, the AMF shall include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. After successful completion of the service request procedure, the network shall perform a local release of all non-emergency PDU sessions. The emergency PDU sessions shall not be released.<br />
<br />
Once the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If any NAS signalling message, having not successfully passed the integrity check, is received, then the NAS in the AMF shall discard that message. If any NAS signalling message is received, as not integrity protected even though the secure exchange of NAS messages has been established, then the NAS shall discard this message.<br />
<br />
=== 4.4.5 Ciphering of NAS signalling messages ===<br />
<span style="color:red">'''The use of ciphering in a network is an operator option subject to AMF configuration'''</span>. <span style="color:red">When operation of the network without ciphering is configured, the AMF shall indicate the use of "null ciphering algorithm" 5G-EA0 (see subclause 9.11.3.34) in the current 5G NAS security context for all UEs</span>. For setting the security header type in outbound NAS messages, the UE and the AMF shall apply the same rules irrespective of whether the "null ciphering algorithm" or any other ciphering algorithm is indicated in the 5G NAS security context.<br />
<br />
<span style="color:red">When the UE establishes a new N1 NAS signalling connection, it shall apply security protection to the initial NAS message as described in subclause 4.4.6.<br />
</span><br />
The UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has been established for an N1 NAS signalling connection. From this time onward, unless explicitly defined, the UE shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.<br />
<br />
The AMF shall start ciphering and deciphering of NAS messages as described in subclause 4.4.2.5. From this time onward, except for the SECURITY MODE COMMAND message, the AMF shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.<br />
<br />
Ciphering is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once the encryption of NAS messages has been started between the AMF and the UE, the receiver shall discard the unciphered NAS messages which shall have been ciphered according to the rules described in this specification.<br />
If the "null ciphering algorithm" 5G-EA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered.<br />
Details of ciphering and deciphering of NAS signalling messages are specified in 3GPP TS 33.501.<br />
<br />
=== 4.4.6 Protection of initial NAS signalling messages ===<br />
The 5GS supports protection of initial NAS messages as specified in 3GPP TS 33.501. <span style="color:red">The protection of initial NAS messages applies to the REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST message</span>, and is achieved as follows:<br />
<ol type="a"><li><span style="color:red">If the UE does not have a valid 5G NAS security context, the UE sends a REGISTRATION REQUEST message including cleartext IEs only.</span> After activating a 5G NAS security context resulting from a security mode control procedure:<br />
<ol><br />
<li>if the UE needs to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message; or</li><br />
<li>if the UE does not need to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs only) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message.</li></ol></li><br />
<li>If the UE has a valid 5G NAS security context and:<br />
<ol><br />
<li>the UE needs to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE includes the entire REGISTRATION REQUEST or SERVICE REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a REGISTRATION REQUEST or SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li><br />
<li>the UE needs to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message:</li><br />
<ol type="i"><br />
:<li>if CIoT small data container IE is the only non-cleartext IE to be sent, the UE shall cipher the value part of the CIoT small data container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the CIoT small data container IE;</li><br />
:<li>otherwise, the UE includes non-cleartext IEs in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li></ol><br />
<li>the UE does not need to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE sends the REGISTRATION REQUEST or SERVICE REQUEST message without including the NAS message container IE; or</li><br />
<li>the UE does not need to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message, the UE sends the CONTROL PLANE SERVICE REQUEST message without including the NAS message container IE and the CIoT small data container IE.</li><br />
</ol><br />
</ol><br />
<span style="color:red">When the initial NAS message is a REGISTRATION REQUEST message, the cleartext IEs are</span>:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* Registration request message identity;<br />
* 5GS registration type;<br />
* ngKSI;<br />
* <span style="color:red">5GS mobile identity</span>;<br />
* UE security capability;<br />
* Additional GUTI;<br />
* UE status;<br />
* EPS NAS message container;<br />
* NID; and<br />
* PLMN with disaster condition.<br />
<br />
When the initial NAS message is a SERVICE REQUEST message, the cleartext IEs are:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* ngKSI;<br />
* Service request message identity;<br />
* Service type; and<br />
* <span style="color:red">5G-S-TMSI</span>.<br />
<br />
When the initial NAS message is a CONTROL PLANE SERVICE REQUEST message, the cleartext IEs are:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* ngKSI;<br />
* Control plane service request message identity; and<br />
* Control plane service type.<br />
<br />
When the UE sends a REGISTRATION REQUEST or SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message that includes a NAS message container IE, the UE shall set the security header type of the initial NAS message to "integrity protected".<br />
<br />
When the AMF receives an integrity protected initial NAS message which includes a NAS message container IE, the AMF shall decipher the value part of the NAS message container IE. If the received initial NAS message is a REGISTRATION REQUEST message or a SERVICE REQUEST message, the AMF shall consider the NAS message that is obtained from the NAS message container IE as the initial NAS message that triggered the procedure.<br />
<br />
When the AMF receives a CONTROL PLANE SERVICE REQUEST message which includes a CIoT small data container IE, the AMF shall decipher the value part of the CIoT small data container IE and handle the message as specified in subclause 5.6.1.4.2.<br />
<br />
When the initial NAS message is a DEREGISTRATION REQUEST message, the UE always sends the NAS message unciphered.<br />
<br />
If the UE:<br />
<ol type="a"><br />
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li><br />
<li>selects a PLMN other than Registered PLMN and EPLMN over one access;</li><br />
</ol><br />
the UE shall send an initial NAS message including cleartext IEs only via the access type associated with the newly selected PLMN as described in this subclause for the case when the UE does not have a valid 5G NAS security context.<br />
<br />
If the UE:<br />
<ol type="a"><br />
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li><br />
<li>selects a PLMN other than Registered PLMN and EPLMN over one access, and the Registered PLMN or EPLMN is not registering or registered over other access;</li><br />
</ol><br />
the UE shall delete the 5G NAS security context.<br />
<br />
:NOTE: UE deletes the 5G NAS security context only if the UE is not in the connected mode.<br />
<br />
=== 4.4.7 Protection of NAS IEs ===<br />
The network can provide the Steering of Roaming (SOR) transparent container Information Element (IE) during the registration procedure to the User Equipment (UE) in the REGISTRATION ACCEPT message. The SOR transparent container IE is integrity protected by the Home Public Land Mobile Network (HPLMN) or subscribed Standalone Non-Public Network (SNPN) as specified in 3GPP TS 33.501.<br />
<br />
The UE can provide the SOR transparent container IE during the registration procedure to the network in the REGISTRATION COMPLETE message. The SoR-MAC-IUE in the SOR transparent container IE is generated by the UE as specified in 3GPP TS 33.501.<br />
<br />
The network can provide the Payload container IE during the Network-initiated NAS transport procedure to the UE in DL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the Payload container IE is integrity protected by the HPLMN or subscribed SNPN as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the payload container entry contents field of the payload container entry is integrity protected correspondingly.<br />
<br />
The UE can provide the Payload container IE during the UE-initiated NAS transport procedure to the network in UL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the Payload container IE is generated by the UE as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the payload container entry contents field of the payload container entry is generated by the UE correspondingly.<br />
<br />
== 4.7 NAS over non-3GPP access ==<br />
<br />
See spec for details<br />
<br />
=== 4.7.1 General ===<br />
From the UE's NAS perspective, in general the procedures and messages defined for 5GMM and 5GSM are used over non-3GPP access as over 3GPP access. However, a number of aspects are different as described in the following subclauses.<br />
<br />
=== 4.7.2 5GS mobility management (5GMM) aspects ===<br />
<br />
==== 4.7.2.1 General ====<br />
The mobility management procedures defined over 3GPP access are re-used over non-3GPP access with certain exceptions. The list goes from a) to s), see spec for details.<br />
<br />
==== 4.7.2.2 Establishment cause for non-3GPP access ====<br />
When establishment of an N1 NAS signalling connection over non-3GPP access is initiated, the UE shall do certain things. See spec for details.<br />
<br />
<br />
=== 4.7.3 5GS session management (5GSM) aspects ===<br />
The session management procedures defined over 3GPP access are re-used over non-3GPP access with the following exceptions:<br />
<ol type="a"><br />
<li>Serving PLMN rate control does not apply for non-3GPP access;</li><br />
<li>Small data rate control does not apply for non-3GPP access;</li><br />
<li>Handling of 5GSM cause value #82 "maximum data rate per UE for user-plane integrity protection is too low" does not apply for non-3GPP access;</li><br />
<li>MBS does not apply for non-3GPP access; and</li><br />
<li>Support of redundant PDU sessions does not apply for non-3GPP access.</li><br />
</ol><br />
<br />
=== 4.7.4 Limited service state over non-3GPP access ===<br />
<br />
There are a number of situations in which the UE is unable to obtain normal service from a PLMN over non-3GPP access and the UE enters the limited service state over non-3GPP access. These include:<br />
<ol type="a"><br />
<li>no Universal Subscriber Identity Module (USIM) in the Mobile Equipment (ME);</li><br />
<li>an "illegal UE" or "illegal ME" is received when registration, network-initiated de-registration or service request is performed (any USIM in the ME is then considered "invalid");</li><br />
<li>a "5GS services not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "PLMN not allowed" is received when registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "Tracking area not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "Roaming not allowed in this tracking area" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>void; or</li><br />
<li>a "Serving network not authorized" is received when a registration or service request is performed.</li><br />
</ol><br />
In limited service state with a valid USIM in the UE, the network selection is performed as defined in 3GPP TS 24.502.<br />
<br />
With the exception of performing initial registration for emergency services, no registration requests are made until a valid USIM is present. For registration for emergency services, the PLMN of the current N3IWF or TNGF is considered as the selected PLMN for the duration the UE is registered for emergency services.<br />
<br />
=== 4.7.5 NAS signalling using trusted WLAN access network ===<br />
<br />
A trusted WLAN interworking function (TWIF) provides functionalities for a non-5G capable over WLAN (N5CW) device to access 5GCN, including:<br />
<ol type="a"><br />
<li>NAS signalling over N1 NAS signalling connection with AMF; and</li><br />
<li>PDU session establishment, modification and release on behalf of the N5CW device, over N2 connection with the AMF.</li><br />
</ol><br />
The TWIF registers on behalf of the N5CW device to an AMF according to subclause 5.5.1.3 by populating the parameters for the registration by using implementation specific default values which are the same for N5CW devices.<br />
<br />
The TWIF may request to establish a PDU session as specified in subclause 6.4.1.2 on behalf of the N5CW device upon receipt of an IP configuration request from the N5CW device by populating either all the required parameters or part of the required parameters for the PDU session establishment by using implementation specific default values from the TWIF's configuration. Only one PDU session is supported when N5CW device accessing 5GC via the TWIF.<br />
<br />
:NOTE 1: If part of the required parameters for the PDU session establishment is provided by the TWIF, the remaining of the required parameters are determined by the AMF or the SMF based on the N5CW device's subscription information.<br />
Upon loss of the IP address of the N5CW device, the TWIF acting on behalf of the N5CW device shall initiate the UE-requested PDU session release procedure as defined in subclause 6.4.3.<br />
<br />
:NOTE 2: The established PDU session on behalf of the N5CW device can be modified by the TWIF or the network.<br />
<br />
== 4.8 Interworking with E-UTRAN connected to EPC ==<br />
<br />
=== 4.8.1 General ===<br />
In order to interwork with E-UTRAN connected to EPC, the UE supporting both S1 mode and N1 mode can operate in single-registration mode or dual-registration mode (see 3GPP TS 23.501). Support of single-registration mode is mandatory for UEs supporting both S1 mode and N1 mode.<br />
<br />
During the EPS attach procedure (see 3GPP TS 24.301) or initial registration procedure (see subclause 5.5.1.2), the mode for interworking is selected if the UE supports both S1 mode and N1 mode, and the network supports interworking. The mode for interworking may also be selected during the EPS tracking area updating procedure (see 3GPP TS 24.301) or registration procedure for mobility and periodic registration update (see subclause 5.5.1.3).<br />
<br />
For interworking between E-UTRAN connected to EPC and TNGF or N3IWF connected to 5GCN, the UE shall operate as specified in either subclause 4.8.2.3 or subclause 4.8.3. Which subclause the UE follows is chosen by the UE irrespective of the interworking without N26 interface indicator.<br />
<br />
=== 4.8.2 Single-registration mode ===<br />
See spec for details...<br />
<br />
=== 4.8.3 Dual-registration mode ===<br />
<br />
If both 5G Mobility Management (5GMM) and EPS Mobility Management (EMM) are enabled, a UE, operating in the dual-registration mode shall maintain independent contexts for 5GMM and EMM and this includes independent lists of equivalent PLMNs. Coordination between 5GMM and EMM is not needed, except as specified in the present subclause, subclause 5.1.5 and 5.3.13A.<br />
<br />
For dual-registration mode the following applies:<br />
<ol type="a"><br />
<li>a UE operating in the dual-registration mode may register to N1 mode only, S1 mode only, or to both N1 mode and S1 mode;</li><br />
<li>when the UE decides to operate in dual-registration mode (see subclause 5.5.1.2.4), NAS informs the lower layers about this;</li><br />
<li>if a UE is registered in N1 mode only, then for registration in S1 mode the UE shall use:</li><br />
# the same PLMN to which it is registered in N1 mode; or<br />
# an equivalent PLMN; and<br />
<li>if a UE is registered in S1 mode only, then for registration in N1 mode the UE shall use:</li><br />
# the same PLMN to which it is registered in S1 mode; or<br />
# an equivalent PLMN.<br />
</ol><br />
:NOTE 1: It is up to UE implementation how to handle the case when the UE is registered in both N1 mode and S1 mode and the PLMNs to which the UE is registered, are not equivalent, e.g. search for a PLMN which is the same or equivalent to any of the registered ones.<br />
<br />
When no PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure with PDN connection establishment if EMM-REGISTERED without PDN connection is not supported by the MME. If EMM-REGISTERED without PDN connection is supported by the MME, the UE may initiate either the EPS attach procedure without PDN connection establishment or the attach procedure with PDN connection establishment.<br />
<br />
When at least one PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure. If necessary, the UE may transfer an active PDU session from N1 mode to S1 mode by initiating the EPS attach procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message. After successfully attached in S1 mode, if necessary, the UE may transfer other active PDU sessions from N1 mode to S1 mode by initiating the PDN connectivity procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message.<br />
<br />
:NOTE 2: It is up to UE implementation to determine which active PDU session is transferred from N1 mode to S1 mode.<br />
<br />
When the UE has not registered to N1 mode, the UE may initiate the initial registration procedure. After successfully registered in N1 mode, if necessary, the UE may transfer one or more active PDN connections from S1 mode to N1 mode by initiating the PDU session establishment procedure with request type set to "existing PDU session".<br />
<br />
:NOTE 3: It is up to UE implementation to determine which active PDN connection is transferred from S1 mode to N1 mode.<br />
<br />
If the MME supports EMM-REGISTERED without PDN connection, the UE that transferred all PDN connections to the 5GS, may stay in state EMM-REGISTERED. Otherwise, the UE shall enter state EMM-DEREGISTERED upon transferring all PDN connection to the 5GS.<br />
<br />
:NOTE 4: When the UE has registered in both N1 mode and S1 mode, it is up to UE implementation to maintain the registration update to date in both N1 mode and S1 mode.<br />
<br />
See subclause 6.1.4 for coordination between 5GSM and ESM.<br />
<br />
See subclause 4.8.2.3.2 for interworking between TNGF or N3IWF connected to 5GCN and E-UTRAN.<br />
<br />
=== 4.8.4 Core Network selection for UEs not using Cellular Internet of Things (CIoT) 5GS optimizations ===<br />
If the UE is capable of both N1 mode and S1 mode, when the UE needs to use one or more functionalities not supported in 5GS but supported in EPS and the UE is in 5GMM-IDLE mode, the UE may disable the N1 mode capability for 3GPP access (see subclause 4.9.2).<br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN without also providing an indication that a target core network type was received from the NG-RAN, the UE shall select a core network type (EPC or 5GCN) based on the PLMN selection procedures as specified in 3GPP TS 23.122 and provide the selected core network type information to the lower layer during the initial registration procedure.<br />
<br />
If the UE is capable of both N1 mode and S1 mode and the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN and an indication of whether the network supports IMS emergency services via either EPC or 5GCN or both (see 3GPP TS 36.331 [25A]), the UE selects a core network type (EPC or 5GCN) as specified in 3GPP TS 23.167 [6] annex H.2 for initiating emergency calls when in the state 5GMM-DEREGISTERED.LIMITED-SERVICE or EMM-DEREGISTERED.LIMITED-SERVICE.<br />
:NOTE 1: If the PLMN selection information provisioned in the USIM does not contain any prioritization between E-UTRAN and NG-RAN for a PLMN, which core network type to select for that PLMN is up to UE implementation.<br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN with:<br />
# an indication that target core network type EPC was received from the NG-RAN, the UE shall select the EPC and proceed with the appropriate EMM procedure as specified in 3GPP TS 24.301; or<br />
# an indication that target core network type 5GCN was received from the NG-RAN, the UE shall select the 5GCN and proceed with the appropriate 5GMM procedure.<br />
:NOTE 2: The NG-RAN can provide a target core network type to the UE during RRC connection release with redirection (see 3GPP TS 36.331 and 3GPP TS 38.331).<br />
<br />
=== 4.8.4A Core Network selection and redirection for UEs using CIoT optimizations ===<br />
<br />
==== 4.8.4A.1 Core network selection ====<br />
A UE that supports CIoT optimizations performs core network selection (i.e. it selects EPC or 5GCN) if the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN as specified in 3GPP TS 23.501.<br />
<br />
When selecting a PLMN as described in 3GPP TS 23.122, the UE shall select a core network type (EPC or 5GCN) based on:<br />
<ol type="a"><br />
<li>indication from the lower layers about the CIoT EPS optimizations supported in EPC;</li><br />
<li>indication from the lower layers about the CIoT 5GS optimizations supported in 5GCN;</li><br />
<li>the CIoT EPS optimizations supported by the UE;</li><br />
<li>the CIoT 5GS optimizations supported by the UE;</li><br />
<li>the UE's preferred CIoT network behaviour for EPC; and</li><br />
<li>the UE's preferred CIoT network behaviour for 5GCN.</li><br />
</ol><br />
<br />
The UE shall provide the selected core network type information to the lower layer during the initial registration procedure.<br />
<br />
==== 4.8.4A.2 Redirection of the UE by the core network ====<br />
The network that supports CIoT optimizations can redirect a UE between EPC and 5GCN as specified in subclause 5.31.3 of 3GPP TS 23.501. The network can take into account the UE's N1 mode capability or S1 mode capability, the CIoT network behaviour supported and preferred by the UE or the CIoT network behaviour supported by the network to determine the redirection.<br />
<br />
:NOTE: It is assumed that the network would avoid redirecting the UE back and forth between EPC and 5GCN.<br />
<br />
The network redirects the UE to EPC by rejecting the registration request or service request with the 5GMM cause #31 "Redirection to EPC required" as specified in subclause 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5. Upon receipt of reject message, the UE disables the N1 mode capability for 3GPP access as specified in subclause 4.9.2 and enables the E-UTRA capability if it was disabled in order to move to EPC.<br />
<br />
When there is no ongoing registration procedure or service request procedure for a UE in 5GMM-CONNECTED mode, if the AMF determines to redirect the UE to EPC, the AMF shall initiate the generic UE configuration update procedure to indicate registration requested and release of the N1 NAS signalling connection not requested as described in subclause 5.4.4. The network then redirects the UE to EPC by rejecting the registration request as specified in subclause 5.5.1.3.5.<br />
<br />
The network that supports CIoT optimizations can also redirect a UE from EPC to 5GCN as specified in subclause 5.3.19.2 of 3GPP TS 24.301.<br />
<br />
== 4.9 Disabling and re-enabling of UE's N1 mode capability ==<br />
<br />
=== 4.9.1 General ===<br />
<br />
The UE shall re-enable the N1 mode capability when the UE powers off and powers on again, the USIM is removed or an entry of the "list of subscriber data" with the SNPN identity of the SNPN is updated.<br />
<br />
=== 4.9.2 Disabling and re-enabling of UE's N1 mode capability for 3GPP access ===<br />
<br />
The UE shall only disable the N1 mode capability for 3GPP access when in 5GMM-IDLE mode.<br />
<br />
When the UE is disabling the N1 mode capability for 3GPP access for a PLMN not due to redirection to EPC, it should proceed as follows:<br />
<ol type="a"><br />
<li>select an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs, if the UE supports S1 mode and the UE has not disabled its E-UTRA capability as specified in 3GPP TS 24.301;</li><br />
<li>if an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, the UE does not support S1 mode or the UE has disabled its E-UTRA capability as specified in 3GPP TS 24.301, the UE may select another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs that the UE supports;</li><br />
<li>if another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, then enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH, or the UE does not have a registered PLMN, then enter the state 5GMM-DEREGISTERED.PLMN-SEARCH and perform PLMN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this PLMN selection. As an implementation option, if the UE does not have a registered PLMN, instead of performing PLMN selection, the UE may select another RAT of the selected PLMN if the UE has chosen a PLMN and the RAT is supported by the UE; or</li><br />
<li>if no other allowed PLMN and RAT combinations are available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered PLMN, and may periodically scan for another PLMN and RAT combination which can provide EPS services or non-EPS services (if the UE supports EPS services or non-EPS services). How this periodic scanning is done, is UE implementation dependent.</li><br />
</ol><br />
When the UE is disabling the N1 mode capability for 3GPP access for an SNPN, it should proceed as follows:<br />
<ol type="a"><br />
<li>enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH and perform SNPN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this SNPN selection; or</li><br />
<li>if no other SNPN is available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered SNPN.</li><br />
</ol><br />
<br />
When the UE is disabling the N1 mode capability upon receiving cause value #31 "Redirection to EPC required" as specified in subclauses 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5, it should proceed as follows:<br />
<ol type="a"><br />
<li>If the UE is in NB-N1 mode:</li><br />
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable NB-IoT cell connected to EPC according to 3GPP TS 36.304;<br />
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or<br />
# if lower layers cannot find a suitable NB-IoT cell connected to EPC or there is no suitable NB-IoT cell connected to EPC which supports CIoT EPS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.<br />
<li>If the UE is in WB-N1 mode:</li><br />
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable E-UTRA cell connected to EPC according to 3GPP TS 36.304;<br />
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, then perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or<br />
# if lower layers cannot find a suitable E-UTRA cell connected to EPC or there is no suitable E-UTRA cell connected to EPC which supports CIoT EPS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.<br />
</ol><br />
<br />
When the UE supporting both N1 mode and S1 mode needs to stay in E-UTRA connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional handover or cell reselection from E-UTRA connected to EPC to NG-RAN connected to 5GCN, the UE operating in single-registration mode shall disable the N1 mode capability for 3GPP access and:<br />
<ol type="a"><br />
<li>shall set the N1mode bit to "N1 mode for 3GPP access not supported" in the UE network capability IE (see 3GPP TS 24.301) of the ATTACH REQUEST message and the TRACKING AREA UPDATE REQUEST message in EPC; and</li><br />
<li>the UE NAS layer shall indicate the access stratum layer(s) of disabling of the N1 mode capability for 3GPP access.</li><br />
</ol><br />
<br />
If the UE is required to disable the N1 mode capability for 3GPP access and select E-UTRA or another RAT, and the UE is in the 5GMM-CONNECTED mode,<br />
* if the UE has a persistent PDU session, then the UE waits until the radio bearer associated with the persistent PDU session has been released;<br />
* otherwise the UE shall locally release the established NAS signalling connection;<br />
<br />
and enter the 5GMM-IDLE mode before selecting E-UTRA or another RAT.<br />
<br />
If the UE is disabling its N1 mode capability for 3GPP access before selecting E-UTRA or another RAT, the UE shall not perform the UE-initiated de-registration procedure of subclause 5.5.2.2.<br />
<br />
The UE shall re-enable the N1 mode capability for 3GPP access when the UE performs PLMN or SNPN selection over 3GPP access, unless<br />
* disabling of the N1 mode capability for 3GPP access was due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off; or<br />
* the UE has already re-enabled the N1 mode capability for 3GPP access when performing items c) or d) above.<br />
<br />
If the disabling of N1 mode capability for 3GPP access was due to IMS voice is not available over 3GPP access and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for 3GPP access when the UE's usage setting is changed from "voice centric" to "data centric", as specified in subclauses 4.3.3.<br />
<br />
The UE should memorize the identity of the PLMN or SNPN where N1 mode capability for 3GPP access was disabled and should use that stored information in subsequent PLMN or SNPN selections as specified in 3GPP TS 23.122.<br />
<br />
If the disabling of N1 mode capability for 3GPP access was due to successful completion of an emergency services fallback, the criteria to enable the N1 mode capability again are UE implementation specific.<br />
<br />
The UE shall disable the N1 mode capability for 3GPP access if requested by the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229). If the UE disabled the N1 mode capability for 3GPP access based on the request from the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229), the criteria to re-enable the N1 mode capability for 3GPP access after the completion of an emergency service are UE implementation specific.<br />
<br />
If the N1 mode capability for 3GPP access was disabled due to the UE initiated de-registration procedure for 3GPP access or for 3GPP access and non-3GPP access and the UE is operating in single-registration mode (see subclause 5.5.2.2.3), upon request of the upper layers to re-register for 5GS services over 3GPP access the UE shall enable the N1 mode capability for 3GPP access again.<br />
<br />
As an implementation option, the UE may start a timer for enabling the N1 mode capability for 3GPP access when the UE's registration attempt counter reaches 5 and the UE disables the N1 mode capability for 3GPP access for cases described in subclauses 5.5.1.2.7 and 5.5.1.3.7. The UE should memorize the identity of the PLMNs where N1 mode capability for 3GPP access was disabled. On expiry of this timer:<br />
* if the UE is in Iu mode or A/Gb mode and is in idle mode as specified in 3GPP TS 24.008 on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access;<br />
* if the UE is in Iu mode and a PS signalling connection exists, but no RR connection exists, the UE may abort the PS signalling connection before enabling the N1 mode capability for 3GPP access; and<br />
* if the UE is in S1 mode and is in EMM-IDLE mode as specified in 3GPP TS 24.301, on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access.<br />
<br />
If the UE is in Iu mode or A/Gb mode and an Radio Resource (RR) connection exists, the UE should delay enabling the N1 mode capability for 3GPP access until the RR connection is released. If the UE is in S1 mode and is in EMM-CONNECTED mode as specified in 3GPP TS 24.301, the UE should delay enabling the N1 mode capability for 3GPP access until the NAS signalling connection in S1 mode is released.<br />
<br />
<pre>A Interface between a BSS and a 2G MSC<br />
Gb Interface between a BSS and a 2G SGSN<br />
Iu-cs Interface between a BSS and a 3G MSC<br />
Iu-ps Interface between a BSS and a 3G SGSN<br />
Iur-g Interface between two BSSs<br />
Um Interface between MS and BSS<br />
<br />
Source: 3GPP TS 43.501</pre><br />
<br />
The UE may disable the N1 mode capability for currently camped PLMN or SNPN over 3GPP access (see 3GPP TS 23.122) if no network slice is available for the camped PLMN or SNPN.<br />
<br />
If the UE attempts to establish an emergency PDU session in a PLMN where N1 mode capability was disabled due to the UE's registration attempt counter have reached 5, the UE may enable N1 mode capability for that PLMN memorized by the UE.<br />
<br />
:NOTE: If N1 mode capability is disabled due to the UE's registration attempt counter reaches 5, the value of the timer for re-enabling N1 mode capability is recommended to be the same as the value of T3502 which follows the handling specified in subclause 5.3.8.<br />
<br />
=== 4.9.3 Disabling and re-enabling of UE's N1 mode capability for non-3GPP access ===<br />
<br />
When the UE disables the N1 mode capability for non-3GPP access, the UE NAS layer shall not initiate any 5GS NAS procedures towards the network over non-3GPP access.<br />
<br />
When the UE supporting both N1 mode and S1 mode needs to stay in non-3GPP access connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional selection of a non-3GPP access network connected to 5GCN, the UE operating in single-registration mode shall not transfer any PDN connection to a non-3GPP access network connected to the 5GCN.<br />
<br />
If the disabling of N1 mode capability for non-3GPP access was due to IMS voice is not available over non-3GPP access in 5GS and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for non-3GPP access when the UE's usage setting is changed from "voice centric" to "data centric" as specified in subclauses 4.3.3.<br />
<br />
The UE shall re-enable the N1 mode capability for non-3GPP access when a new PLMN or SNPN is selected over non-3GPP access.<br />
<br />
:NOTE: In SNPN, the term "UE's N1 mode capability for non-3GPP access" in this subclause refers to the UE's N1 mode capability to access SNPN services via a PLMN.<br />
<br />
The UE may disable the N1 mode capability for the currently camped PLMN or SNPN over non-3GPP access if no network slice is available for the camped PLMN or SNPN.<br />
<br />
As an implementation option, the UE may start a timer for re-enabling the N1 mode capability for non-3GPP access, after the N1 mode capability for non-3GPP access was disabled. On the expiry of this timer, the UE should re-enable the N1 mode capability for non-3GPP access.<br />
<br />
== 4.11 UE configuration parameter updates ==<br />
<br />
The 5GS in a PLMN supports updating UE parameters via NAS signalling. The feature enables the HPLMN to securely and dynamically re-configure the UE configuration parameters stored on the USIM and the ME.<br />
<br />
See spec for details...<br />
<br />
== 4.13 Support of NAS signalling using wireline access network ==<br />
A 5G-RG, a W-AGF acting on behalf of an FN-RG or a W-AGF acting on behalf of an N5GC device can use wireline access network to access the 5GCN by using NAS signalling procedures as described in 3GPP TS 23.501, 3GPP TS 23.502 and 3GPP TS 23.316.<br />
<br />
Wireline access is a type of non-3GPP access.<br />
<br />
A 5G-RG simultaneously connected to the same 5GCN of a PLMN over a 3GPP access and a wireline access is connected to a single AMF.<br />
<br />
5G-RG maintains the N1 NAS signalling connection with the AMF over the wireline access network after all the PDU sessions for the 5G-RG over that access have been released or handed over to 3GPP access.<br />
<br />
See spec for details...<br />
<br />
== 4.14 Non-public network (NPN) ==<br />
=== 4.14.1 General ===<br />
Two types of NPN can be deployed using 5GS: SNPN (see subclause 4.14.2) and PNI-NPN (see subclause 4.14.3).<br />
<br />
==== 4.14.2 Stand-alone non-public network ====<br />
If the UE is not SNPN enabled, the UE is always considered to be not operating in SNPN access operation mode. If the UE is SNPN enabled, the UE can operate in SNPN access operation mode. Details of activation and deactivation of SNPN access operation mode at the SNPN enabled UE are up to UE implementation.<br />
<br />
The functions and procedures of NAS described in the present document are applicable to an SNPN and an SNPN enabled UE unless indicated otherwise.<br />
<br />
See spec for details...<br />
<br />
=== 4.14.3 Public network integrated non-public network (PNI-NPN) ===<br />
<br />
A PNI-NPN is made available by means of e.g. dedicated DNNs or by one or more S-NSSAIs allocated for it. A CAG can be optionally used in order to prevent UEs not allowed to access a PNI-NPN from accessing the PNI-NPN.<br />
<br />
See spec for details...<br />
<br />
== 4.16 UE radio capability signalling optimization ==<br />
<br />
See spec for details...<br />
<br />
== 4.17 5GS mobility management in NB-N1 mode ==<br />
<br />
See spec for details...<br />
<br />
== 4.19 5GS mobility management in WB-N1 mode for IoT ==<br />
<br />
See spec for details...<br />
<br />
== 4.20 5GS session management in WB-N1 mode for IoT ==<br />
<br />
See spec for details...<br />
<br />
== 4.23 NAS over Non-Terrestrial Network ==<br />
<br />
See spec for details...<br />
<br />
== 4.24 Minimization of service interruption (MINT) ==<br />
<br />
The UE and the network may support Minimization of service interruption (MINT). MINT aims to enable a UE to obtain service from a PLMN offering disaster roaming service when a disaster condition applies to the UE's determined PLMN with disaster condition.<br />
<br />
If the UE supports MINT, the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "list of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range provisioned by the network, if available, are stored in the non-volatile memory in the ME as specified in annex C and are kept when the UE enters 5GMM-DEREGISTERED state. Annex C specifies condition under which the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "lists of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range stored in the ME are deleted.<br />
<br />
See spec for details...<br />
<br />
== 4.25 Support of MUSIM features ==<br />
<pre>MUSIM UE: A UE with multiple valid Universal Subscriber Identity Modules (USIMs), capable of initiating and maintaining simultaneous separate registration states over 3GPP access with PLMN(s) using identities and credentials associated with those USIMs and supporting one or more of the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control (see 3GPP TS 23.501).<br />
<br />
Source: 3GPP TS 24.501</pre><br />
<br />
A network and a MUSIM UE may support one or more of the MUSIM features (i.e. the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control).<br />
<br />
If MUSIM UE supports one or more MUSIM features, the UE indicates support of one or more MUSIM features (except for the paging timing collision control) during the registration procedure. If the UE has indicated support of the N1 NAS signalling connection release or the reject paging request or both and the UE supports the paging restriction, the UE indicates support of the paging restriction.<br />
<br />
If the UE indicates support of one or more MUSIM features and the network decides to accept one or more MUSIM features, the network indicates the support of one or more MUSIM features during the registration procedure. The network only indicates the support of the paging restriction together with the support of either N1 NAS signalling connection release or the reject paging request.<br />
<br />
The network does not indicate support for any MUSIM feature to the UE during the registration for emergency services.<br />
<br />
If a UE stops fulfilling the condition to be considered a MUSIM UE as defined in subclause 3.1, and the UE has negotiated support of one or more MUSIM features, then the UE shall initiate a registration procedure for mobility and periodic registration update to indicate that all the MUSIM features are not supported (except for the paging timing collision control) as specified in subclause 5.5.1.3.<br />
<br />
A MUSIM UE operating in NB-N1 mode or in WB-N1 mode CE mode B does not indicate the support for paging indication for voice services during the registration procedure towards the network.<br />
<br />
== 5.1 Overview ==<br />
<br />
=== 5.1.1 General ===<br />
<br />
The main function of the 5GS mobility management (5GMM) sublayer is to support the identification, security, mobility of a UE as well as generic message transport.<br />
<br />
A further function of the 5GMM sublayer is to provide connection management services to the other sublayer(s).<br />
<br />
:NOTE: In a satellite NG-RAN access, a GNSS fix time in lower layers can delay transmission of an initial UL NAS message by up to 100 seconds (GNSS cold state).<br />
<br />
=== 5.1.2 Types of 5GMM procedures ===<br />
Depending on how they can be initiated, three types of 5GMM procedures can be distinguished:<br />
* 5GMM common procedures<br />
* 5GMM specific procedures<br />
* 5GMM connection management procedures<br />
<br />
Three types of 5GMM procedures broken out...<br />
<br />
<ol type="a"><br />
<li>5GMM common procedures:<br />
<br />
5GMM common procedure can always be initiated when the UE is in 5GMM-CONNECTED mode. The procedures belonging to this type are:</li><br />
<ol type="1"><br />
<li>Initiated by the network:</li><br />
<ol type="i"><br />
<li>network-initiated NAS transport;</li><br />
<li>primary authentication and key agreement;</li><br />
<li>security mode control;</li><br />
<li>generic UE configuration update;</li><br />
<li>identification; and</li><br />
<li>network slice-specific authentication and authorization;</li><br />
</ol><br />
<li>Initiated by the UE:<br />
<br />
:UE-initiated NAS transport.</li><br />
<li>Initiated by the UE or the network and used to report certain error conditions detected upon receipt of 5GMM protocol data:<br />
<br />
:5GMM status.</li><br />
</ol><br />
<li>5GMM specific procedures:<br />
<br />
:At any time only one UE initiated 5GMM specific procedure can be running for each of the access network(s) that the UE is camping in. The procedures belonging to this type are:</li><br />
<ol type="1"><br />
<li>Initiated by the UE and used e.g. to register to the network for 5GS services and establish a 5GMM context, to update the location/parameter(s) of the UE:<br />
<br />
:registration.</li><br />
<li>Initiated by the UE or the network and used to deregister from the network for 5GS services and to release a 5GMM context:<br />
<br />
:de-registration.</li><br />
<li>Initiated by the UE and used to deregister from the network for 5GS services and to release a 5GMM context:<br />
<br />
:eCall inactivity procedure.</li><br />
</ol><br />
<li>5GMM connection management procedures:</li><br />
<ol type="1"><br />
<li>Initiated by the UE and used to establish a secure connection to the network or to request the resource reservation for sending data, or both:<br />
<br />
:service request.<br />
<br />
The service request procedure can only be initiated if no UE initiated 5GMM specific procedure is ongoing for each of the access network(s) that the UE is camping in.</li><br />
<li>Initiated by the network and used to request the establishment of an N1 NAS signalling connection or to request re-establishment of user-plane resources for the PDU session(s) associated with 3GPP access or to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access; not applicable for the non-3GPP access network:<br />
<br />
:paging.</li><br />
<li>Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access or to deliver 5GSM downlink signalling messages associated with non-3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over 3GPP access and in 5GMM-IDLE mode over non-3GPP access; or<br><br><br />
<br />
Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with 3GPP access over 3GPP access or to deliver downlink signalling associated with 3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over non-3GPP access, and when the UE is in 5GMM-IDLE mode over 3GPP access and not in MICO mode:<br />
<br />
:notification.</li><br />
</ol><br />
</ol><br />
<br />
:NOTE 1: In NB-N1 mode, the UE NAS using 5GS services with control plane CIoT 5GS optimization can wait for the lower layers to complete the transmission of the previous UL NAS TRANSPORT messages carrying control plane user data before providing subsequent NAS messages. Other implementations are possible.<br />
<br />
:NOTE 2: When providing NAS messages to the lower layers for transmission, the UE NAS using 5GS services with control plane CIoT 5GS optimization can prioritize sending NAS signalling messages over the UL NAS TRANSPORT messages carrying control plane user data. How the UE performs this prioritization is implementation specific.<br />
<br />
=== 5.1.3 5GMM sublayer states ===<br />
<br />
==== 5.1.3.1 General ====<br />
<br />
In the following subclauses, the 5GS mobility management (5GMM) sublayer of the UE and the network is described by means of different state machines. The 5GMM sublayer states is managed per access type independently, i.e. 3GPP access or non-3GPP access. In subclause 5.1.3.2, the states of the 5GMM sublayer are introduced.<br />
<br />
===== 5.1.3.2.1 5GMM sublayer states in the UE =====<br />
<br />
See spec, lots of info...<br />
<br />
===== 5.1.3.2.2 5GS update status in the UE =====<br />
<br />
In order to describe the detailed UE behaviour, the 5GS update (5U) status pertaining to a specific subscriber is defined.<br />
<br />
If the UE is not operating in SNPN access operation mode (see 3GPP TS 23.501), the 5GS update status is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.<br />
<br />
If the UE is operating in SNPN access operation mode, the 5GS update status for each SNPN whose SNPN identity is included in the "list of subscriber data" configured in the ME (see 3GPP TS 23.122) is stored in the non-volatile memory in the ME as described in annex C.<br />
<br />
The 5GS update status value is changed only after the execution of a registration, network-initiated de-registration, 5GS based primary authentication and key agreement, service request, paging procedure or due to change in the current TAI which does not belong to the current registration area while T3346 is running.<br />
<br />
:5U1: UPDATED<br />
::The last registration attempt was successful.<br />
:5U2: NOT UPDATED<br />
::The last registration or service request attempt failed procedurally, e.g. no response or reject message was received from the AMF.<br />
:5U3: ROAMING NOT ALLOWED<br />
::The last registration, service request, or registration for mobility or periodic registration update attempt was correctly performed, but the answer from the AMF was negative (because of roaming or subscription restrictions).<br />
<br />
===== 5.1.3.2.3 5GMM sublayer states in the network side =====<br />
<br />
There are four 5GMM sublayer states in the network side.<br />
<br />
; 5GMM-DEREGISTERED : In the state 5GMM-DEREGISTERED, no 5GMM context has been established or the 5GMM context is marked as deregistered. The UE is deregistered. The network may answer to an initial registration procedure initiated by the UE. The network may also answer to a de-registration procedure initiated by the UE.<br />
; 5GMM-COMMON-PROCEDURE-INITIATED : The network enters the state 5GMM-COMMON-PROCEDURE-INITIATED, after it has started a common 5GMM procedure and is waiting for a response from the UE.<br />
; 5GMM-REGISTERED : In the state 5GMM-REGISTERED, a 5GMM context has been established. Additionally, one or more PDU session(s) may be established at the network.<br />
; 5GMM-DEREGISTERED-INITIATED : The network enters the state 5GMM-DEREGISTERED-INITIATED after it has started a de-registration procedure and is waiting for a response from the UE.<br />
<br />
=== 5.1.4 Coordination between 5GMM and EMM ===<br />
<br />
==== 5.1.4.1 General ====<br />
If both 5GMM and EMM are enabled, a UE, operating in single-registration mode, shall maintain one common registration for 5GMM for 3GPP access and EMM.<br />
<br />
Coordination between 5GMM for 3GPP access and EMM for a UE, which is capable of N1 mode and S1 mode and operates in dual-registration mode, is not needed, except as specified in subclause 4.8.3.<br />
<br />
The coordination between 5GMM for 3GPP access and EMM in subclauses 5.1.4.2 and 5.1.4.3 only applies to the UEs operating in single-registration mode.<br />
<br />
Regarding the coordination of "SIM/USIM considered invalid" and "USIM considered invalid for 5GS services" between the various mobility management entities see subclause 5.1.5.<br />
<br />
==== 5.1.4.2 Coordination between 5GMM for 3GPP access and EMM with N26 interface ====<br />
<br />
;N26 interface:N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core.<br />
<br />
A UE that is not registered shall be in state EMM-DEREGISTERED and state 5GMM-DEREGISTERED for 3GPP access.<br />
<br />
In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter (see 3GPP TS 24.301).<br />
<br />
At inter-system change from S1 mode to N1 mode, the UE shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP accessand EMM-REGISTERED.NO-CELL-AVAILABLE and initiate a registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).<br />
<br />
In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter or tracking area updating attempt counter (see 3GPP TS 24.301).<br />
<br />
At inter-system change from N1 mode to S1 mode when there is no active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, and EMM-REGISTERED without PDN connection is not supported by the UE or the MME, the UE shall enter state 5GMM-DEREGISTERED for 3GPP access and state EMM-DEREGISTERED and then initiate the EPS attach procedure. If EMM-REGISTERED without PDN connection is supported by the UE and the MME, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure.<br />
<br />
At inter-system change from N1 mode to S1 mode when there is at least one active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure (see 3GPP TS 24.301).<br />
<br />
==== 5.1.4.3 Coordination between 5GMM for 3GPP access and EMM without N26 interface ====<br />
<br />
A UE operating in the single-registration mode that is not registered over 3GPP access shall be in state EMM-DEREGISTERED and in state 5GMM-DEREGISTERED for 3GPP access.<br />
<br />
In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE.<br />
<br />
At inter-system change from N1 mode to S1 mode in 5GMM-IDLE mode, the UE shall behave as specified in subclause 4.8.2.3.<br />
<br />
In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE.<br />
<br />
At inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, the UE operating in the single-registration mode shall enter substates EMM-REGISTERED.NO-CELL-AVAILABLE and 5GMM- REGISTERED.NORMAL-SERVICE for 3GPP access and then initiate the registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).<br />
<br />
=== 5.1.5 Coordination between 5GMM and GMM ===<br />
<br />
Coordination between 5GMM and GMM states is not required.<br />
<br />
Regardless whether the UE is operating in single-registration mode or dual-registration mode,<br />
* if the UE considers the SIM/USIM invalid for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the SIM/USIM invalid for all of them; and<br />
* if the UE considers the USIM invalid for 5GS services for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the USIM invalid for 5GS services for all of them.<br />
<br />
== 5.3 General on elementary 5G Mobility Management (5GMM) procedures ==<br />
<br />
=== 5.3.1 5GMM modes and N1 NAS signalling connection ===<br />
<br />
==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====<br />
When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial Non-Access Stratum (NAS) message, the User Equipment (UE) shall request the lower layer to establish an Radio Resource Controller (RRC) connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access.<br />
<br />
When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access.<br />
<br />
Initial NAS messages are:<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST message;</li><br />
<li>DEREGISTRATION REQUEST message;</li><br />
<li>SERVICE REQUEST message; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST.</li><br />
</ol><br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.<br />
<br />
For the routing of the initial NAS message to the appropriate AMF, if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules...see spec<br />
<br />
== 5.2 Behaviour of the UE in state 5GMM-DEREGISTERED and state 5GMM-REGISTERED ==<br />
<br />
== 5.3 General on elementary 5GMM procedures ==<br />
<br />
=== 5.3.1 5GMM modes and N1 NAS signalling connection ===<br />
<br />
==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====<br />
<br />
<span style="color:red">When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial NAS message, the UE shall request the lower layer to establish an RRC connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access</span>.<br />
<br />
<span style="color:red">When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access</span>.<br />
<br />
Initial NAS messages are:<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST message;</li><br />
<li>DEREGISTRATION REQUEST message;</li><br />
<li>SERVICE REQUEST message; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST.</li><br />
</ol><br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.<br />
<br />
For the routing of the initial NAS message to the appropriate AMF, <span style="color:red">if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules</span>:<br />
<ol type="a"><br />
<li>if the registration procedure for mobility and periodic update was triggered due to the last CONFIGURATION UPDATE COMMAND message containing the Configuration update indication IE with the Registration bit set to "registration requested" and including:<br />
# no other parameters;<br />
# one or both of the Allowed NSSAI IE and the Configured NSSAI IE; or<br />
# the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed";<br />
:the <span style="color:red">UE NAS shall not provide the lower layers with the 5G-S-TMSI or the registered GUAMI</span>;</li><br />
<li>if the service request procedure was initiated over non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the registered GUAMI, but shall not provide the lower layers with the 5G-S-TMSI</span>;</li><br />
<li>if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over untrusted non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI</span>;<br />
<br />
if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over trusted non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the 5G-GUTI, if available, otherwise shall provide the lower layers with the SUCI</span>;<br />
<br />
if the UE is the 5G-RG and the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over wireline access, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, if available, otherwise shall not provide the lower layers with any UE identity</span>;</li><br />
<li>if the UE does not hold a 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration procedure and if:<br />
# the UE operating in the single-registration mode performs a registration procedure for mobility and periodic update indicating "mobility registration updating" following an inter-system change from S1 mode to N1 mode; or<br />
# the UE which was previously registered in S1 mode before entering state EMM-DEREGISTERED, performs an initial registration procedure, the UE has received the interworking without N26 interface indicator set to "interworking without N26 interface not supported" from the network, and the UE holds a 4G-GUTI;<br />
<br />
then <span style="color:red">the UE NAS provides the lower layers with a GUAMI part of the 5G-GUTI mapped from 4G-GUTI as specified in 3GPP TS 23.003 with an indication that the GUAMI is mapped from EPS</span>; or</li><br />
<li>otherwise:<br />
# if the tracking area of the current cell is in the registration area, <span style="color:red">the UE NAS shall provide the lower layers with the 5G-S-TMSI, but shall not provide the registered GUAMI to the lower layers</span>; or<br />
# if the tracking area of the current cell is not in the registration area, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclauses 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI</span>.</li><br />
</ol><br />
<br />
<br />
For 3GPP access and untrusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, <span style="color:red">the UE NAS does not provide the lower layers with the 5G-S-TMSI or the registered GUAMI</span>. For trusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, <span style="color:red">the UE NAS provides the lower layers with the SUCI</span>.<br />
<br />
The UE NAS also provides the lower layers with the identity of the selected PLMN (see 3GPP TS 38.331) if the UE is not operating in SNPN access operation mode. If the UE is operating in SNPN access operation mode, the UE NAS provides the lower layers with the SNPN identity of the selected SNPN. In a shared network, the UE shall choose one of the PLMN identity(ies) or SNPN identity(ies) as specified in 3GPP TS 23.122.<br />
<br />
The UE NAS layer may provide the lower layers with an NSSAI as specified in subclause 4.6.2.3.<br />
<br />
If the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the UE NAS layer shall provide the lower layers with an indication that the connection is for onboarding.<br />
<br />
==== 5.3.1.2 Re-establishment of the N1 NAS signalling connection ====<br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li><span style="color:red">initiate the registration procedure for mobility and periodic registration update</span> and include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.5.1.3 for further details).</li><br />
</ol><br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has pending uplink user data for PDU session(s) with user-plane resources already established but no pending NAS procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication (see subclause 5.6.1 for further details).</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending registration procedure, a service request procedure, or a de-registration procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode;</li><br />
<li>proceed with the pending procedure; and</li><br />
<li>if the pending procedure is a service request or <span style="color:red">registration procedure</span> and the SERVICE REQUEST message, the CONTROL PLANE SERVICE REQUEST message or the REGISTRATION REQUEST message does not include UE request type IE with Request type value set to "NAS signalling connection release", the UE shall include the Uplink data status IE in the SERVICE REQUEST message, or <span style="color:red">in the REGISTRATION REQUEST message</span>, indicating the PDU session(s) for which user-plane resources were not active prior to receiving a fallback indication from the lower layers and the UE has pending user data to be sent over 3GPP access, if any, and the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclauses 5.5.1.3 and 5.6.1 for further details).</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending NAS procedure other than a registration procedure, a service request procedure, or a de-registration procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode;</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details); and</li><br />
<li>upon successful service request procedure completion, proceed with any pending procedure.</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, and the UE was using network resources for ProSe direct discovery over PC5 or ProSe direct communication over PC5 (see 3GPP TS 23.304), the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details).</li><br />
</ol><br />
The cases above apply when the UE is in an allowed area or when the UE is not in a non-allowed area.<br />
<br />
When the UE:<br />
<ol type="a"><br />
<li>is in a non-allowed area or is not in an allowed area;</li><br />
<li>is in 5GMM-CONNECTED mode over 3GPP access;</li><br />
<li>receives a fallback indication from lower layers; and</li><br />
<li>does not have signalling pending,</li><br />
</ol><br />
the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li><span style="color:red">initiate the registration procedure for mobility and periodic registration update</span>. The UE shall not include the Uplink data status IE in the REGISTRATION REQUEST message except if the PDU session for which user-plane resources were active is an emergency PDU session, or if the UE is configured for high priority access in the selected PLMN.</li><br />
</ol><br />
<br />
In the above cases when the UE receives a fallback indication from lower layers, if the UE is in non-allowed area or not in allowed area, the UE shall behave as specified in subclause 5.3.5.<br />
<br />
==== 5.3.1.3 Release of the N1 NAS signalling connection ====<br />
<br />
See spec for details...<br />
<br />
==== 5.3.1.4 5GMM-CONNECTED mode with RRC inactive indication ====<br />
<br />
See spec for details...<br />
<br />
==== 5.3.1.5 Suspend and resume of the N1 NAS signalling connection ====<br />
<br />
See spec for details...<br />
<br />
=== 5.3.2 Permanent identifiers ===<br />
A globally unique permanent identity, the 5G subscription permanent identifier (SUPI), is allocated to each subscriber for 5GS-based services. The IMSI, the network specific identifier, the GCI and the GLI are valid SUPI types. When the SUPI contains a network specific identifier, a GCI or a GLI, it shall take the form of a network access identifier (NAI). When the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the SUPI contains the onboarding SUPI derived from the default UE credentials for primary authentication. The UE derives the onboarding SUPI before or during the initial registration for onboarding services in SNPN and uses the derived onboarding SUPI in the initial registration for onboarding services in SNPN and while registered for onboarding services in SNPN.<br />
<br />
The structure of the SUPI and its derivatives are specified in 3GPP TS 23.003. See [[My 3GPP TS 23.003 notes]]<br />
<br />
The UE provides the SUPI to the network in concealed form. The SUCI is a privacy preserving identifier containing the concealed SUPI. When the SUPI contains a network specific identifier, a GCI or a GLI, the SUCI shall take the form of a NAI as specified in 3GPP TS 23.003.<br />
<br />
<span style="color:red">A UE supporting N1 mode includes a SUCI:</span><br />
<ol type="a"><br />
<li>in the REGISTRATION REQUEST message when the UE is attempting initial registration procedure <span style="color:red">and a valid 5G-GUTI is not available</span>;</li><br />
<li>in the IDENTITY RESPONSE message, <span style="color:red">if the SUCI is requested by the network during the identification procedure</span>; and</li><br />
<li>in the DEREGISTRATION REQUEST message when the UE initiates a de-registration procedure <span style="color:red">and a valid 5G-GUTI is not available</span>.</li><br />
</ol><br />
<span style="color:red">If the UE uses the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI, the SUCI contains the unconcealed SUPI.</span><br />
<br />
When:<br />
* not operating in SNPN access operation mode; or<br />
* operating in SNPN access operation mode but not performing initial registration for onboarding services and not registered for onboarding services;<br />
<br />
the UE shall use the "null-scheme" if:<br />
<ol type="a"><br />
<li>the home network has not provisioned the public key needed to generate a SUCI;</li><br />
<li>the home network has configured "null-scheme" to be used for the UE;</li><br />
<li>the UE needs to perform a registration procedure for emergency services after the failure of authentication procedure or after reception of a REGISTRATION REJECT message with the 5GMM cause #3 "Illegal UE", or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully, and the UE does not have a valid 5G-GUTI for the selected PLMN; or</li><br />
<li>the UE receives an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully.</li><br />
</ol><br />
<br />
When operating in SNPN access operation mode and:<br />
* performing initial registration for onboarding services; or<br />
* registered for onboarding services;<br />
<br />
the UE shall use the "null-scheme" if:<br />
<ol type="a"><br />
<li>the public key needed to generate a SUCI is not configured as part of the default UE credentials for primary authentication; or</li><br />
<li>"null-scheme" usage is configured as part of the default UE credentials.</li><br />
</ol><br />
<br />
If:<br />
<ol type="a"><br />
<li>the UE uses the "null-scheme" as specified in 3GPP TS 33.501 [24] to generate a SUCI;</li><br />
<li>the UE operates in SNPN access operation mode and:<br />
# an indication to use anonymous SUCI which is associated with the selected entry of the "list of subscriber data", is configured in the ME, if the UE is not registering or registered for onboarding services in SNPN; or<br />
# an indication to use anonymous SUCI which is associated with the default UE credentials, is configured in the ME, if the UE is registering or registered for onboarding services in SNPN;</li><br />
NOTE 1: The ME can be configured with an indication to use anonymous SUCI associated with an entry of "list of subscriber data" when the EAP method associated with the credentials of the entry supports SUPI privacy at the EAP layer, or can be configured with an indication to use anonymous SUCI associated with the default UE credentials when the EAP method associated with the default UE credentials supports SUPI privacy at the EAP layer, or both.<br />
</br></br><br />
Editor's note: (WI eNPN, CR 4139) it is FFS whether another UE-level configuration for usage of anonymous SUCI is needed.<br />
<br />
<li>the UE does not need to perform a registration procedure for emergency services, or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully; and</li><br />
<li>the UE does not receive an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully;</li><br />
</ol><br />
then the UE shall use anonymous SUCI as specified in 3GPP TS 23.003.<br />
<br />
A W-AGF acting on behalf of an FN-RG shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.<br />
<br />
A W-AGF acting on behalf of an N5GC device shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.<br />
<br />
If a UE is a MUSIM UE, the UE shall use a separate permanent equipment identifier (PEI) for each USIM, if any, and each entry of "list of subscriber data", if any, the UE operates for accessing 5GS-based services; otherwise, a UE contains and uses a permanent equipment identifier (PEI) for accessing 5GS-based services. When the UE is registered with a network by using a PEI, the UE shall not use that PEI to register with another network until the UE is de-registered from the network.<br />
<br />
In this release of the specification, the IMEI, the IMEISV, the MAC address together with the MAC address usage restriction indication and the EUI-64 are the only PEI formats supported by 5GS. The structure of the PEI and its formats are specified in 3GPP TS 23.003.<br />
<br />
Each UE supporting at least one 3GPP access technology (i.e. satellite NG-RAN, NG-RAN, E-UTRAN, UTRAN or GERAN) contains a PEI in the IMEI format and shall be able to provide an IMEI and an IMEISV upon request from the network.<br />
<br />
Each UE not supporting any 3GPP access technologies and supporting NAS over untrusted or trusted non-3GPP access shall have a PEI in the form of the Extended Unique Identifier EUI-64 of the access technology the UE uses to connect to the 5GC.<br />
<br />
A UE supporting N1 mode includes a PEI:<br />
<ol type="a"><br />
<li>when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";</li><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTITY RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
<br />
Each 5G-RG supporting only wireline access and each FN-RG shall have a permanent MAC address configured by the manufacturer. For 5G-CRG, the permanent MAC address configured by the manufacturer shall be a cable modem MAC address.<br />
<br />
When the 5G-RG contains neither an IMEI nor an IMEISV, the 5G-RG shall use as a PEI the 5G-RG's permanent MAC address configured by the manufacturer and the MAC address usage restriction indication set to "no restrictions".<br />
<br />
The Wireless Access Gateway Function (W-AGF) acting on behalf of the Fixed Network Residential Gateway (FN-RG) shall use as a PEI the MAC address provided by the FN-RG and if the MAC address provided by the FN-RG is not unique or does not correspond to the FN-RG's permanent MAC address according to W-AGF's configuration, the MAC address usage restriction indication set to "MAC address is not usable as an equipment identifier" otherwise the MAC address usage restriction indication set to "no restrictions".<br />
<br />
The 5G-RG containing neither an IMEI nor an IMEISV shall include the PEI containing the MAC address together with the MAC address usage restriction indication:<br />
<ol type="a"><br />
<li>when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";</li><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
:NOTE 2: In case c) above, the MAC address is provided even though AMF requests the IMEISV.<br />
<br />
The W-AGF acting on behalf of the FN-RG shall include the PEI containing the MAC address together with the MAC address usage restriction indication:<br />
<ol type="a"><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
:NOTE 3: In case b) above, the MAC address is provided even though AMF requests the IMEISV.<br />
<br />
The W-AGF acting on behalf of the N5GC device shall use as a PEI the MAC address provided by the N5GC device and the MAC address usage restriction indication set to "no restrictions". Based on operator policy, the W-AGF acting on behalf of the N5GC device may encode the MAC address of the N5GC device using the EUI-64 format as specified in IEEE "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" and use as a PEI the derived EUI-64.<br />
:NOTE 4: The MAC address of an N5GC device is universally/globally unique.<br />
<br />
The AMF can request the PEI at any time by using the identification procedure.<br />
<br />
=== 5.3.3 Temporary identities ===<br />
<br />
<span style="color:red">A temporary user identity for 5GS-based services, the 5G globally unique temporary identity (5G-GUTI), is used for identification within the signalling procedures. In case of PLMN the 5G-GUTI is globally unique and in case of Standalone Non-Public Network (SNPN) the 5G-GUTI is unique within an SNPN. When the UE is registered to the same PLMN or SNPN over 3GPP and non-3GPP access, the UE and the AMF maintain one 5G-GUTI that is common to both 3GPP and non-3GPP access. When the UE is required to delete the 5G-GUTI according to a NAS procedure, the UE shall delete the 5G-GUTI only if it is not registered to the same PLMN or SNPN through other access. When the UE is registered to different PLMNs or SNPNs over 3GPP access and non-3GPP access, the UE maintains two 5G-GUTIs, a 5G-GUTI for the registration with a PLMN or SNPN over the 3GPP access and another 5G-GUTI for the registration with another PLMN or SNPN over the non-3GPP access. In the paging and service request procedures, a shortened form of the 5G-GUTI, the 5G S-temporary mobile subscriber identity (5G-S-TMSI), is used to enable more efficient radio signalling. The purpose of the 5G-GUTI and 5G-S-TMSI is to provide identity confidentiality, i.e., to protect a user from being identified and located by an intruder.</span> The structure of the 5G-GUTI and its derivatives are specified in 3GPP TS 23.003. The 5G-GUTI has two main components (see 3GPP TS 23.501):<br />
<ol type="a"><li>the GUAMI; and</li><br />
<li>the 5G-TMSI that provides an unambiguous identity of the UE within the AMF(s) identified by the GUAMI.</li><br />
</ol><br />
:NOTE: The UE registered with an SNPN over non-3GPP access refers to the UE accessing SNPN services via a PLMN.<br />
<br />
The 5G-S-TMSI has three main components:<br />
<ol type="a"><br />
<li>the AMF set ID that uniquely identifies the AMF set within the AMF region;</li><br />
<li>the AMF pointer that identifies one or more AMFs within the AMF set; and</li><br />
<li>the 5G-TMSI.</li><br />
</ol><br />
<br />
A UE supporting N1 mode includes a valid 5G-GUTI, if any is available, in the REGISTRATION REQUEST and DEREGISTRATION REQUEST messages. In the SERVICE REQUEST message, the UE includes a valid 5G-S-TMSI as user identity. <span style="color:red">The AMF shall assign a new 5G-GUTI for a particular UE</span>:<br />
<ol type="a"><br />
<li><span style="color:green">during a successful initial registration procedure</span>;</li><br />
<li><span style="color:green">during a successful registration procedure for mobility registration update</span>;</li><br />
<li><span style="color:green">after a successful service request procedure invoked as a response to a paging request from the network and before</span> the:<br />
# release of the N1 NAS signalling connection; or<br />
# suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;<br />
:as specified in subclause 5.4.4.1; and</li><br />
<li><span style="color:green">after the AMF receives an indication from the lower layers that it has received the NGAP UE context resume request message as specified in 3GPP TS 38.413 for a UE in 5GMM-IDLE mode with suspend indication and this resumption is a response to a paging request from the network, and before</span> the:<br />
# release of the N1 NAS signalling connection; or<br />
# suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;<br />
:as specified in subclause 5.4.4.1.</li><br />
</ol><br />
<br />
<span style="color:red">The AMF should assign a new 5G-GUTI for a particular UE during a successful registration procedure for periodic registration update.</span> <span style="color:red">The AMF may assign a new 5G-GUTI at any time for a particular UE by performing the generic UE configuration update procedure.</span><br />
<br />
If a new 5G-GUTI is assigned by the AMF, the UE and the AMF handle the 5G-GUTI as follows:<br />
<ol type="a"><li>Upon receipt of a 5GMM message containing a new 5G-GUTI, the UE considers the new 5G-GUTI as valid and the old 5G-GUTI as invalid, stops timer T3519 if running, and deletes any stored SUCI. The new 5G-GUTI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.</li><br />
<li>The AMF considers the old 5G-GUTI as invalid as soon as an acknowledgement for a registration or generic UE configuration update procedure is received.</li><br />
</ol><br />
<br />
=== 5.3.4 Registration areas ===<br />
<br />
Within the 5GS, <span style="color:red">the registration area is managed independently per access type, i.e., 3GPP access or non-3GPP access. The AMF assigns a registration area to the UE during the registration procedure</span>. A registration area is defined as a set of tracking areas and each of these tracking areas consists of one or more cells that cover a geographical area. Within the 5GS, the concept of "registration to multiple tracking areas" applies:<br />
<ol type="a"><br />
<li>A tracking area is identified by a TAI which is broadcast in the cells of the tracking area. The TAI is constructed from a TAC and a PLMN identity. In case of a shared network:<br />
<ol type="1"><li>one or more TACs; and</li><br />
<li>any of the following:<br />
<ol type="i"><br />
<li>multiple PLMN identities;</li><br />
<li>multiple SNPN identities; or</li><br />
<li>one or more PLMN identities and one or more SNPN identities;<br />
are broadcast.</li></ol><br />
</li></ol><br />
<li>In order to reduce the tracking area update signalling within the 5GS, the AMF can assign several tracking areas to the UE. These tracking areas construct a list of tracking areas which is identified by a TAI list. When generating the TAI list, the AMF shall include only TAIs that are applicable on the access where the TAI list is sent. The AMF shall be able to allocate a TAI list over different NG-RAN access technologies. The AMF shall not allocate a TAI list containing both tracking areas in NB-N1 mode and tracking areas not in NB-N1 mode.</li><br />
<li>The UE considers itself registered to a list of tracking areas and does not need to trigger the registration procedure for mobility and periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) as long as the UE stays in one of the tracking areas of the list of tracking areas received from the AMF.</li><br />
<li>The UE will consider the TAI list as valid, until it receives a new TAI list in the next registration procedure for mobility and periodic registration update or generic UE configuration update procedure, or the UE is commanded by the network to delete the TAI list by a reject message or it is deregistered from the 5GS. If the registration request is accepted or the TAI list is reallocated by the AMF, the AMF shall provide at least one entry in the TAI list. If the new and the old TAI list are identical, the AMF does not need to provide the new TAI list to the UE during mobility registration update or periodic registration update.</li><br />
<li>The TAI list can be reallocated by the AMF.</li><br />
<li>When the UE is deregistered from the 5GS, the TAI list in the UE is invalid.</li><br />
<li>The UE includes the last visited registered TAI, if available, to the AMF. The last visited registered TAI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.</li><br />
</ol><br />
<br />
=== 5.3.5 Service area restrictions ===<br />
<br />
==== 5.3.5.1 General ====<br />
<br />
Service area restrictions are applicable only to 3GPP access and to wireline access.<br />
<br />
Subclause 5.3.5.2 applies when the UE accesses 5GCN over 3GPP access.<br />
<br />
Subclause 5.3.5.3 applies when the 5G-RG or the W-AGF acting on behalf of an FN-CRG (or on behalf of the N5GC device) access 5GCN over wireline access.<br />
:NOTE: Service area restrictions are not applicable for the W-AGF acting on behalf of the FN-BRG.<br />
<br />
==== 5.3.5.2 3GPP access service area restrictions ====<br />
<br />
<span style="color:blue">The service area restrictions consist of tracking areas forming either an allowed area, or a non-allowed area</span>. The tracking areas belong to either the registered PLMN or its equivalent PLMNs in the registration area. The allowed area can contain up to 16 tracking areas or include all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area. The non-allowed area can contain up to 16 tracking areas. The network conveys the service area restrictions to the UE by including either an allowed area, or a non-allowed area, but <span style="color:red">not both</span>, in the Service area list IE of a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message.<br />
<br />
If the network does not convey the service area restrictions to the UE in the Service area list IE of a REGISTRATION ACCEPT message, the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".<br />
<br />
When the UE receives a Service area list IE with an allowed area indication during a registration procedure or a generic UE configuration update procedure:<br />
<ol type="a"><br />
<li>if the "Type of list" included in the Service area list IE does not indicate "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall delete the old list of "allowed tracking areas" and store the tracking areas in the allowed area as the list of "allowed tracking areas". If the UE has a stored list of "non-allowed tracking areas", the UE shall delete that list; or</li><br />
<li>if the "Type of list" included in the Service area list IE indicates "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".</li><br />
</ol><br />
<br />
When the UE receives a Service area list IE with a non-allowed area indication during a registration procedure or a generic UE configuration update procedure, the UE shall delete the old list of "non-allowed tracking areas" and store the tracking areas in the non-allowed area as the list of "non-allowed tracking areas". If the UE has a stored list of "allowed tracking areas", the UE shall delete that list.<br />
<br />
If the UE is successfully registered to a PLMN and has a stored list of "allowed tracking areas":<br />
<br />
See spec for details...<br />
<br />
=== 5.3.6 Mobile initiated connection only (MICO) mode ===<br />
<br />
=== 5.3.7 Handling of the periodic registration update timer and mobile reachable timer ===<br />
<br />
The periodic registration update procedure is used over 3GPP access to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic registration update timer, T3512.<br />
<br />
If the UE is registered over the 3GPP access, the AMF maintains an implicit de-registration timer to control when the UE is considered implicitly de-registered over the 3GPP access. If the UE is registered over the non-3GPP access, the AMF also maintains a non-3GPP implicit de-registration timer to control when the UE is considered implicitly de-registered over the non-3GPP access. The UE registered over the non-3GPP access maintains a non-3GPP de-registration timer to control when the UE is considered implicitly de-registered for the non-3GPP access.<br />
<br />
The AMF shall start a non-3GPP implicit de-registration timer for the UE registered over non-3GPP access when the N1 NAS signalling connection over non-3GPP access is released.<br />
<br />
The UE registered over non-3GPP access shall reset and start a non-3GPP de-registration timer when the N1 NAS signalling connection over non-3GPP access is released. The non-3GPP de-registration timer is stopped when the UE enters 5GMM-CONNECTED mode over non-3GPP access or the 5GMM-DEREGISTERED state over non-3GPP access.<br />
<br />
The non-3GPP implicit de-registration timer shall be longer than the non-3GPP de-registration timer.<br />
<br />
The value of timer T3512 is sent by the network to the UE in the REGISTRATION ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE until a new value is received. The periodic registration update timer only applies to the UE registered to the 5GS services over 3GPP access.<br />
<br />
If timer T3512 received by the UE in a REGISTRATION ACCEPT message contains an indication that the timer is deactivated or the timer value is zero, then timer T3512 is deactivated and the UE shall not perform the periodic registration update procedure.<br />
:NOTE 1: The UE does not perform the periodic registration update procedure for non-3GPP access.<br />
<br />
If during the registration procedure, the AMF does not indicate "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is reset and started with its initial value, when the UE changes from 5GMM-CONNECTED over 3GPP access to 5GMM-IDLE mode over 3GPP access. Timer T3512 is stopped when the UE enters 5GMM-CONNECTED mode over 3GPP access or the 5GMM-DEREGISTERED state over 3GPP access.<br />
<br />
If during the registration procedure, the AMF indicates "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is started with its initial value after the completion of the registration procedure. The UE shall neither stop nor reset the timer T3512 when the UE enters 5GMM-CONNECTED or when changing from 5GMM-CONNECTED mode to 5GMM-IDLE mode. If the timer T3512 expires,<br />
<ol type="a"><br />
<li>the UE in 5GMM-CONNECTED mode over 3GPP access shall reset and start the timer T3512 with its initial value; or</li><br />
<li>the UE in 5GMM-IDLE mode over 3GPP access shall perform the periodic registration procedure.</li><br />
</ol><br />
<br />
If the UE is registered for emergency services, and timer T3512 expires, the UE shall not initiate a periodic registration update procedure, but shall locally de-register from the network. When the UE is camping on a suitable cell, it may re-register to regain normal service.<br />
<br />
When a UE is not registered for emergency services, and timer T3512 expires when the UE is in 5GMM-IDLE mode, the periodic registration update procedure shall be started.<br />
<br />
If the UE is not registered for emergency services, and is in a state other than 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access when timer T3512 expires, the periodic registration update procedure is delayed until the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access.<br />
:NOTE 2: When the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE and it needs to initiate other 5GMM procedure than the periodic registration update procedure then, based on UE implementation, the 5GMM procedure can take precedence.<br />
<br />
The network supervises the periodic registration update procedure of the UE by means of the mobile reachable timer.<br />
<br />
If the UE is not registered for emergency services, the mobile reachable timer shall be longer than the value of timer T3512. In this case, by default, the mobile reachable timer is 4 minutes greater than the value of timer T3512.<br />
<br />
The network behaviour upon expiry of the mobile reachable timer is network dependent, but typically the network stops sending paging messages to the UE on the first expiry, and may take other appropriate actions.<br />
<br />
If the UE is registered for emergency services, the AMF shall set the mobile reachable timer with a value equal to timer T3512. When the mobile reachable timer expires, the AMF shall locally de-register the UE.<br />
<br />
The mobile reachable timer shall be reset and started with the value as indicated above, when the AMF releases the NAS signalling connection for the UE. The mobile reachable timer shall be stopped when a NAS signalling connection is established for the UE.<br />
<br />
Upon expiry of the mobile reachable timer the network shall start the implicit de-registration timer over 3GPP access. The value of the implicit de-registration timer over 3GPP access is network dependent. If MICO mode is activated, the network shall start the implicit de-registration timer over 3GPP access when the UE enters 5GMM-IDLE mode at the AMF over 3GPP access. The default value of the implicit de-registration timer over 3GPP access is 4 minutes greater than the value of timer T3512.<br />
<br />
If the implicit de-registration timer expires before the UE contacts the network, the network shall implicitly de-register the UE. The implicit de-registration timer shall be stopped when a NAS signalling connection is established for the UE.<br />
<br />
If the non-3GPP implicit de-registration timer expires before the UE contacts the network over the non-3GPP access, the network shall implicitly de-register the UE and enter the state 5GMM-DEREGISTERED over non-3GPP access for the UE. The non-3GPP implicit de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.<br />
<br />
If the non-3GPP de-registration timer expires before the UE contacts the network over the non-3GPP access, the UE shall enter the state 5GMM-DEREGISTERED over non-3GPP access. The non-3GPP de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.<br />
<br />
If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "Non-3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of timer T3512, the AMF sets the mobile reachable timer and the implicit de-registration timer such that the sum of the timer values is greater than the value of timer T3346.<br />
<br />
If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the AMF sets the non-3GPP implicit de-registration timer value to be 8 minutes greater than the value of timer T3346.<br />
<br />
If the UE receives T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the UE sets the non-3GPP de-registration timer value to be 4 minutes greater than the value of timer T3346.<br />
<br />
=== 5.3.9 Handling of NAS level mobility management congestion control ===<br />
<br />
== 5.4 5GMM common procedures ==<br />
<br />
=== 5.4.2 Security mode control (SMC) procedure ===<br />
<br />
==== 5.4.2.1 General ====<br />
<br />
The purpose of the NAS security mode control procedure is to take a 5G NAS security context into use, and initialise and start NAS signalling security between the UE and the AMF with the corresponding 5G NAS keys and 5G NAS security algorithms.<br />
<br />
See spec for details...<br />
<br />
=== 5.4.3 Identification procedure ===<br />
<br />
==== 5.4.3.1 General ====<br />
<br />
The purpose of this procedure is to request a particular UE to provide specific identification parameters, e.g. the SUCI, the IMEI, the IMEISV, the EUI-64 or the MAC address. The SUCI is a privacy preserving identifier containing the concealed SUPI and the IMEI, the IMEISV, the EUI-64 and the MAC address are formats of PEI.<br />
<br />
See spec for details...<br />
<br />
== 5.5 5GMM specific procedures ==<br />
<br />
=== 5.5.1 Registration procedure ===<br />
<br />
==== 5.5.1.1 General ====<br />
<br />
The registration procedure is always initiated by the UE and used for initial registration as specified in subclause 5.5.1.2.2 or mobility and periodic registration update as specified in subclause 5.5.1.3.2.<br />
<br />
When the UE needs to initiate registration over both 3GPP access and non-3GPP access in the same PLMN (e.g. the 3GPP access and the selected N3IWF are located in the same PLMN), the UE:<br />
<ol type="a"><br />
<li>in 5GMM-REGISTERED-INITIATED over 3GPP access shall not initiate registration over non-3GPP access; or</li><br />
<li>in 5GMM-REGISTERED-INITIATED over non-3GPP access shall not initiate registration over 3GPP access.</li><br />
:NOTE 1: To which access (i.e. 3GPP access or non-3GPP access) the UE initiates registration first is up to UE implementation.<br />
</ol><br />
<br />
When the UE is registered with a PLMN over a non-3GPP access, the AMF and the UE maintain:<br />
<ol type="a"><br />
<li>registration state and state machine over non-3GPP access;</li><br />
<li>5G NAS security context;</li><br />
<li>5G-GUTI;</li><br />
<li>registration area for non-3GPP access, which is associated with a single TAI; and</li><br />
<li>non-3GPP de-registration timer in the UE and non-3GPP implicit de-registration timer in the AMF.</li><br />
</ol><br />
<br />
A registration attempt counter is used to limit the number of subsequently rejected registration attempts. The registration attempt counter shall be incremented as specified in subclause 5.5.1.2.7 or subclause 5.5.1.3.7. Depending on the value of the registration attempt counter, specific actions shall be performed. The registration attempt counter shall be reset when:<br />
* the UE is powered on;<br />
* a USIM is inserted;<br />
* a registration procedure is successfully completed;<br />
* an EPS attach or combined EPS attach procedure is successfully completed in S1 mode and the UE is operating in single-registration mode. In this case, the UE shall reset the registration attempt counter for 3GPP access;<br />
:NOTE 2: The registration attempt counter for non-3GPP access is not impacted by the EPS attach and the combined EPS attach procedure.<br />
* a registration procedure is rejected with cause #11, #12, #13, #15, #27, #31, #62, #72, #73, #74, #75, #76, #77 or #78;<br />
* a registration procedure is rejected with cause #3, #6 or #7, the REGISTRATION REJECT message is received without integrity protection and the counter for "SIM/USIM considered invalid for GPRS services" events has a value less than a UE implementation-specific maximum value.<br />
* a network initiated deregistration procedure is completed with cause #11, #12, #13, #15, #27; #62, #72, #74, #75, #76, #77 or #78; or<br />
* a new PLMN or SNPN is selected.<br />
<br />
Additionally, the registration attempt counter shall be reset when the UE is in substate 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION or 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE, and:<br />
* the current TAI is changed;<br />
* timer T3502 expires; or<br />
* timer T3346 is started.<br />
When the registration attempt counter is reset, the UE shall stop timer T3519 if running, and delete any stored SUCI.<br />
<br />
The lower layers indicate to NAS whether the network supports emergency services for the UE in limited service state (see 3GPP TS 38.331). This information is taken into account when deciding whether to initiate an initial registration for emergency services.<br />
<br />
==== 5.5.1.2 Registration procedure for initial registration ====<br />
<br />
===== 5.5.1.2.1 General =====<br />
<br />
This procedure can be used by a UE for initial registration for 5GS services.<br />
<br />
When the UE initiates the registration procedure for initial registration, the UE shall indicate "initial registration" in the 5GS registration type IE. When the UE initiates the registration procedure for emergency services, the UE shall indicate "emergency registration" in the 5GS registration type IE. When the UE initiates the initial registration for onboarding services in SNPN, the UE shall indicate "SNPN onboarding registration" in the 5GS registration type IE. When the UE initiates the initial registration procedure for disaster roaming services, the UE shall indicate "disaster roaming initial registration" in the 5GS registration type IE.<br />
<br />
If the MUSIM UE initiates the registration procedure for initial registration and indicates "emergency registration" in the 5GS registration type IE in the REGISTRATION REQUEST message, the network shall not indicate the support of:<br />
* the N1 NAS signalling connection release;<br />
* the paging indication for voice services;<br />
* the reject paging request; or<br />
* the paging restriction;<br />
in the REGISTRATION ACCEPT message.<br />
<br />
===== 5.5.1.2.2 Initial registration initiation =====<br />
The UE in state 5GMM-DEREGISTERED shall initiate the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF,<br />
<ol type="a"><br />
<li>when the UE performs initial registration for 5GS services;</li><br />
<li>when the UE performs initial registration for emergency services;</li><br />
<li>when the UE performs initial registration for SMS over NAS;</li><br />
<li>when the UE moves from GERAN to NG-RAN coverage or the UE moves from a UTRAN to NG-RAN coverage and the following applies:<br />
# the UE initiated a GPRS attach or routing area updating procedure while in A/Gb mode or Iu mode; or<br />
# the UE has performed 5G-SRVCC from NG-RAN to UTRAN as specified in 3GPP TS 23.216,<br />
:and since then the UE did not perform a successful EPS attach or tracking area updating procedure in S1 mode or registration procedure in N1 mode;<br />
<li>when the UE performs initial registration for onboarding services in SNPN; and</li><br />
<li>when the UE performs initial registration for disaster roaming services;</li><br />
</ol><br />
with the following clarifications to initial registration for emergency services:<br />
<ol type="a"><br />
<li>the UE shall not initiate an initial registration for emergency services over the current access, if the UE is already registered for emergency services over the non-current access, unless the initial registration has to be initiated to perform handover of an existing emergency PDU session from the non-current access to the current access; and</li><br />
NOTE 1: Transfer of an existing emergency PDU session between 3GPP access and non-3GPP access is needed e.g. if the UE determines that the current access is no longer available.<br />
<li>the UE can only initiate an initial registration for emergency services over non-3GPP access if it cannot register for emergency services over 3GPP access.</li><br />
</ol><br />
<br />
The UE initiates the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF, starting timer T3510. If timer T3502 is currently running, the UE shall stop timer T3502. If timer T3511 is currently running, the UE shall stop timer T3511.<br />
<br />
<span style="color:red">During initial registration the UE handles the 5GS mobile identity IE in the following order:</span><br />
<ol type="a"><br />
<li>if:<br />
<ol type="1"><br />
<li>the UE:</li><br />
<ol type="i"><br />
<li>was previously registered in S1 mode before entering state EMM-DEREGISTERED; and</li><br />
<li>has received an "interworking without N26 interface not supported" indication from the network; and</li><br />
</ol><br />
<li>EPS security context and a valid native 4G-GUTI are available;</li><br />
</ol><br />
<br />
then the UE shall create a 5G-GUTI mapped from the valid native 4G-GUTI as specified in 3GPP TS 23.003 and indicate the mapped 5G-GUTI in the 5GS mobile identity IE. The UE shall include the UE status IE with the EMM registration status set to "UE is not in EMM-REGISTERED state" and shall include an ATTACH REQUEST message as specified in 3GPP TS 24.301 in the EPS NAS message container IE.<br />
<br />
Additionally, if the UE holds a valid 5G GUTI, the UE shall include the 5G-GUTI in the Additional GUTI IE in the REGISTRATION REQUEST message in the following order:<br />
# a valid 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration, if available;<br />
# a valid 5G-GUTI that was previously assigned by an equivalent PLMN, if available; and<br />
# a valid 5G-GUTI that was previously assigned by any other PLMN, if available;<br />
<br />
<li>if:<br />
# the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same PLMN with which the UE is performing the registration, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or<br />
# the UE is registering with a SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same SNPN with which the UE is performing the registration, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;</li><br />
<br />
<li>if the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by an equivalent PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;</li><br />
<br />
<li>if:<br />
# the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or<br />
# the UE is registering with an SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other SNPN, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE and shall additionally include the NID of the other SNPN in the NID IE;</li><br />
<br />
<li>if a SUCI other than an onboarding SUCI is available, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall include the SUCI other than an onboarding SUCI in the 5GS mobile identity IE;</li><br />
<li>if the UE does not hold a valid 5G-GUTI or SUCI other than an onboarding SUCI, and is initiating the initial registration for emergency services, the PEI shall be included in the 5GS mobile identity IE; and</li><br />
<li>if the UE is initiating the initial registration for onboarding services in SNPN, an onboarding SUCI shall be included in the 5GS mobile identity IE.</li><br />
</ol><br />
:NOTE 2: The AMF in ON-SNPN uses the onboarding SUCI as specified in 3GPP TS 23.501.<br />
<br />
If the SUCI is included in the 5GS mobile identity IE and the timer T3519 is not running, the UE shall start timer T3519 and store the value of the SUCI sent in the REGISTRATION REQUEST message. The UE shall include the stored SUCI in the REGISTRATION REQUEST message while timer T3519 is running.<br />
<br />
If the UE is operating in the dual-registration mode and it is in EMM state EMM-REGISTERED, the UE shall include the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state".<br />
<br />
:NOTE 3: Inclusion of the UE status IE with this setting corresponds to the indication that the UE is "moving from EPC" as specified in 3GPP TS 23.502.<br />
:NOTE 4: The value of the 5GMM registration status included by the UE in the UE status IE is not used by the AMF.<br />
<br />
If the last visited registered TAI is available, the UE shall include the last visited registered TAI in the REGISTRATION REQUEST message.<br />
<br />
If the UE requests the use of SMS over NAS, the UE shall include the 5GS update type IE in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS supported". When the 5GS update type IE is included in the REGISTRATION REQUEST for reasons other than requesting the use of SMS over NAS, and the UE does not need to register for SMS over NAS, the UE shall set the SMS requested bit of the 5GS update type IE to "SMS over NAS not supported" in the REGISTRATION REQUEST message.<br />
<br />
See spec for more info...<br />
<br />
...<br />
<br />
If the UE does not have a valid 5G NAS security context, <span style="color:red">the UE shall send the REGISTRATION REQUEST message without including the NAS message container IE.</span> The UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs and non-cleartext IEs, if any) in the NAS message container IE that is sent as part of the SECURITY MODE COMPLETE message as described in subclauses 4.4.6 and 5.4.2.3.<br />
<br />
If the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6. If the UE does not need to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message without including the NAS message container IE.<br />
<br />
<br />
...<br />
<br />
== 8.2 5GS mobility management messages ==<br />
<br />
=== 8.2.6 Registration Request ===<br />
<br />
==== 8.2.6.1 Message definition ====<br />
The REGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.6.1.1.<br />
;Message type:REGISTRATION REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
{| class="wikitable"<br />
|+ Table 8.2.6.1.1: REGISTRATION REQUEST message content<br />
|-<br />
! IEI !! Information Element !! Type/Reference !! Presence !! Format !! Length<br />
|-<br />
| || Extended protocol discriminator || Extended Protocol discriminator 9.2 || M || V || 1<br />
|-<br />
| || Security header type || Security header type 9.3 || M || V || 1/2<br />
|-<br />
| || Spare half octet || Spare half octet 9.5 || M || V || 1/2<br />
|-<br />
| || Registration request message identity || Message type 9.7 || M || V || 1<br />
|-<br />
| || 5GS registration type || 5GS registration type 9.11.3.7 || M || V || 1/2<br />
|-<br />
| || ngKSI || NAS key set identifier 9.11.3.32 || M || V || 1/2<br />
|-<br />
| || <span style="color:red">5GS mobile identity</span> || <span style="color:red">5GS mobile identity 9.11.3.4</span> || M || LV-E || 6-n<br />
|-<br />
| C- || Non-current native NAS key set identifier || NAS key set identifier 9.11.3.32 || O || TV || 1<br />
|-<br />
| 10 || 5GMM capability || 5GMM capability 9.11.3.1 || O || TLV || 3-15<br />
|-<br />
| 2E || UE security capability || UE security capability 9.11.3.54 || O || TLV || 4-10<br />
|-<br />
| 2F || Requested NSSAI || NSSAI 9.11.3.37 || O || TLV || 4-74<br />
|-<br />
| 52 || Last visited registered TAI || 5GS tracking area identity 9.11.3.8 || O || TV || 7<br />
|-<br />
| 17 || S1 UE network capability || S1 UE network capability 9.11.3.48 || O || TLV || 4-15<br />
|-<br />
| 40 || Uplink data status || Uplink data status 9.11.3.57 || O || TLV || 4-34<br />
|-<br />
| 50 || PDU session status || PDU session status 9.11.3.44 || O || TLV || 4-34<br />
|-<br />
| B- || MICO indication || MICO indication 9.11.3.31 || O || TV || 1<br />
|-<br />
| 2B || UE status || UE status 9.11.3.56 || O || TLV || 3<br />
|-<br />
| 77 || Additional GUTI || 5GS mobile identity 9.11.3.4 || O || TLV-E || 14<br />
|-<br />
| 25 || Allowed PDU session status || Allowed PDU session status 9.11.3.13 || O || TLV || 4-34<br />
|-<br />
| 18 || UE's usage setting || UE's usage setting 9.11.3.55 || O || TLV || 3<br />
|-<br />
| 51 || Requested DRX parameters || 5GS DRX parameters 9.11.3.2A || O || TLV || 3<br />
|-<br />
| 70 || EPS NAS message container || EPS NAS message container 9.11.3.24 || O || TLV-E || 4-n<br />
|-<br />
| 74 || LADN indication || LADN indication 9.11.3.29 || O || TLV-E || 3-811<br />
|-<br />
| 8- || Payload container type || Payload container type 9.11.3.40 || O || TV || 1<br />
|-<br />
| 7B || Payload container || Payload container 9.11.3.39 || O || TLV-E || 4-65538<br />
|-<br />
| 9- || Network slicing indication || Network slicing indication 9.11.3.36 || O || TV || 1<br />
|-<br />
| 53 || 5GS update type || 5GS update type 9.11.3.9A || O || TLV || 3<br />
|-<br />
| 41 || Mobile station classmark 2 || Mobile station class mark 2 9.11.3.31C || O || TLV || 5<br />
|-<br />
| 42 || Supported codecs || Supported codec list 9.11.3.51A || O || TLV || 5-n<br />
|-<br />
| 71 || NAS message container || NAS message container 9.11.3.33 || O || TLV-E || 4-n<br />
|-<br />
| 60 || EPS bearer context status || EPS bearer context status 9.11.3.23A || O || TLV || 4<br />
|-<br />
| 6E || Requested extended DRX parameters || Extended DRX parameters 9.11.3.26A || O || TLV || 3<br />
|-<br />
| 6A || T3324 value || GPRS timer 3 9.11.2.5 || O || TLV || 3<br />
|-<br />
| 67 || UE radio capability ID || UE radio capability ID 9.11.3.68 || O || TLV || 3-n<br />
|-<br />
| 35 || Requested mapped NSSAI || Mapped NSSAI 9.11.3.31B || O || TLV || 3-42<br />
|-<br />
| 48 || Additional information requested || Additional information requested 9.11.3.12A || O || TLV || 3<br />
|-<br />
| 1A || Requested WUS assistance information || WUS assistance information 9.11.3.71 || O || TLV || 3-n<br />
|-<br />
| A- || N5GC indication || N5GC indication 9.11.3.72 || O || TV || 1<br />
|-<br />
| 30 || Requested NB-N1 mode DRX parameters || NB-N1 mode DRX parameters 9.11.3.73 || O || TLV || 3<br />
|-<br />
| 29 || UE request type || UE request type 9.11.3.76 || O || TLV || 3<br />
|-<br />
| 28 || Paging restriction || Paging restriction 9.11.3.77 || O || TLV || 3-35<br />
|-<br />
| 72 || Service-level-AA container || Service-level-AA container 9.11.2.10 || O || TLV-E || 6-n<br />
|-<br />
| 32 || NID || NID 9.11.3.79 || O || TLV || 8<br />
|-<br />
| 16 || MS determined PLMN with disaster condition || PLMN identity 9.11.3.85 || O || TLV || 5<br />
|-<br />
| 2A || Requested PEIPS assistance information || PEIPS assistance information 9.11.3.80 || O || TLV || 3-n<br />
|}<br />
<br />
See spec for details of each message.<br />
<br />
==== 8.2.6.21 NAS message container ====<br />
This IE shall be included if the UE is sending a REGISTRATION REQUEST message as an initial NAS message, the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs.<br />
<br />
=== 8.2.12 De-registration request (UE originating de-registration) ===<br />
<br />
==== 8.2.12.1 Message definition ====<br />
The DEREGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.12.1.1.<br />
<br />
;Message type:DEREGISTRATION REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
=== 8.2.16 Service request ===<br />
<br />
==== 8.2.16.1 Message definition ====<br />
The SERVICE REQUEST message is sent by the UE to the AMF in order to request the establishment of an N1 NAS signalling connection and/or to request the establishment of user-plane resources for PDU sessions which are established without user-plane resources. See table 8.2.16.1.1.<br />
<br />
;Message type:SERVICE REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
=== 8.2.30 Control Plane Service request ===<br />
<br />
==== 8.2.30.1 Message definition ====<br />
The CONTROL PLANE SERVICE REQUEST message is sent by the UE to the AMF when the UE is using 5GS services with control plane CIoT 5GS optimization. See table 8.2.30.1.1.<br />
<br />
;Message type:CONTROL PLANE SERVICE REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
== 9.1 General message format and information elements coding Overview ==<br />
See spec for details of section 9.<br />
<br />
=== 9.1.1 NAS message format ===<br />
<br />
Within the protocols defined in the present document, every 5GS NAS message is a standard L3 message as defined in 3GPP TS 24.007.<br />
<br />
== 9.11 Other information elements ==<br />
<br />
=== 9.11.1 General ===<br />
<br />
<span style="color:red">The different formats (V, LV, T, TV, TLV, LV-E, TLV-E) and the five categories of information elements (type 1, 2, 3, 4 and 6) are defined in 3GPP TS 24.007.</span><br />
<br />
The first octet of an information element in the non-imperative part contains the IEI of the information element. If this octet does not correspond to an IEI known in the message, the receiver shall determine whether this IE is of type 1 or 2 (i.e., it is an information element of one octet length) or an IE of type 4 (i.e., that the next octet is the length indicator indicating the length of the remaining of the information element) (see 3GPP TS 24.007).<br />
<br />
This allows the receiver to jump over unknown information elements and to analyze any following information elements of a particular message.<br />
<br />
The definitions of information elements which are:<br />
<ol type="a"><br />
<li>common for the 5GMM and 5GSM protocols;</li><br />
<li>used by access stratum protocols; or</li><br />
<li>sent to upper layers</li><br />
</ol><br />
are described in subclause 9.11.2.<br />
<br />
The information elements of the 5GMM or 5GSM protocols can be defined by reference to an appropriate specification which provides the definition of the information element, e.g., "see subclause 10.5.6.3A in 3GPP TS 24.008".<br />
<br />
See spec for details...<br />
<br />
=== 9.11.3 5GS mobility management (5GMM) information elements ===<br />
<br />
See spec for details...<br />
<br />
==== <span style="color:red">9.11.3.4 5GS mobile identity</span> ====<br />
<br />
<span style="color:red">The purpose of the 5GS mobile identity information element is to provide either the SUCI, the 5G-GUTI, the IMEI, the IMEISV, the 5G-S-TMSI, the MAC address or the EUI-64.</span><br />
<br />
The 5GS mobile identity information element is coded as shown in figures 9.11.3.4.1, 9.11.3.4.2, 9.11.3.4.3, 9.11.3.4.4, 9.11.3.4.5, 9.11.3.4.6, 9.11.3.4.8 and 9.11.3.4.7, and table 9.11.3.4.1.<br />
<br />
The 5GS mobile identity is a type 6 information element with a minimum length of 4.<br />
<br />
See spec for figures and details...<br />
<br />
<br />
<center>[[Telecommunications info|To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_24.501_notes&diff=3033My 3GPP 24.501 notes2023-07-16T15:16:14Z<p>Paul: /* 4.4.1 General */</p>
<hr />
<div>== 1 Scope ==<br />
3GPP TS 24.501 document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
The 5GS session management (5GSM) protocol defined in the present document provides procedures for the handling of 5GS PDU sessions. Together with the bearer control provided by the access stratum, this protocol is used for the control of user-plane resources.<br />
<br />
For both NAS protocols the present document specifies procedures for the support of inter-system mobility between the NG-RAN and the evolved universal terrestrial radio access (E-UTRAN), between the NG-RAN and the non-3GPP access network connected to the EPC, and between the non-3GPP access network connected to the 5G core network (5GCN) and the E-UTRAN.<br />
<br />
For both NAS protocols the present document specifies procedures for the support of mobility between the NG-RAN and the non-3GPP access network connected to the 5GCN.<br />
<br />
In addition, the present document specifies the procedures in the 5GS for UE policy delivery service between the UE and the policy control function (PCF) for both 3GPP access and non-3GPP access.<br />
<br />
The present document is applicable to the UE, the access and mobility management function (AMF), the session management function (SMF), and the PCF in the 5GS.<br />
<br />
The clauses and subclauses in the present document are common for both 3GPP access and non-3GPP access unless it is explicitly stated that they apply to 3GPP access only or non-3GPP access only.<br />
<br />
== 4.1 Overview ==<br />
The <span style="color:red">non-access stratum (NAS) described in 24.501 forms the highest stratum of the control plane between UE and AMF</span> (reference point "N1" see 3GPP TS 23.501) for both 3GPP and non-3GPP access.<br />
<br />
Main functions of the protocols that are part of the NAS are:<br />
* support of mobility of the user equipment (UE) including also common procedures such as authentication, identification, generic UE configuration update and security mode control procedures;<br />
* support of session management procedures to establish and maintain data connectivity between the UE and the data network; and<br />
* NAS transport procedure to provide a transport of SMS, LPP, LCS, UE policy container, SOR transparent container and UE parameters update information payload.<br />
<br />
Principles for the handing of 5GS security contexts and for the activation of ciphering and integrity protection, when a NAS signalling connection is established, are provided in subclause 4.4.<br />
<br />
For the support of the above functions, the following procedures are supplied within this specification:<br />
* elementary procedures for 5GS mobility management in clause 5; and<br />
* elementary procedures for 5GS session management in clause 6.<br />
<br />
Signalling procedures for the control of NAS security are described as part of the 5GMM common procedures in subclause 5.4.<br />
<br />
Complete NAS transactions consist of specific sequences of elementary procedures. Examples of such specific sequences can be found in 3GPP TS 23.502.<br />
<br />
The NAS for 5GS follows the protocol architecture model for layer 3 as described in 3GPP TS 24.007.<br />
<br />
== 4.2 Coordination between the protocols for 5GS mobility management and 5GS session management ==<br />
A 5G system (5GS) session management (5GSM) message is piggybacked in specific 5GS mobility management (5GMM) transport messages. To this purpose, the 5GSM messages can be transmitted in an information element in the 5GMM transport messages. In this case, the UE, the AMF and the SMF execute the 5GMM procedure and the 5GSM procedure in parallel. The success of the 5GMM procedure is not dependent on the success of the piggybacked 5GSM procedure.<br />
<br />
<span style="color:red">The UE can only initiate the 5GSM procedure when there is a 5GMM context established at the UE.</span><br />
<br />
During 5GMM procedures, the UE and the AMF shall suspend the transmission of 5GSM messages, except when:<br />
<ol type="a"><br />
<li>the 5GMM procedure is piggybacking 5GSM messages; or</li><br />
<li>the UE is in 5GMM-CONNECTED mode and a service request procedure for re-establishing user-plane resources of PDU session(s) is initiated without including PDU session status IE or Allowed PDU session status IE. In this case, the UE and the AMF need not suspend the transmission of 5GSM messages related to other PDU session(s) than the one(s) for which the user- plane resources re-establishment is requested.</li><br />
</ol><br />
<br />
If the UE determines to locally release the N1 NAS signalling connection upon receiving an Steering of Roaming (SOR) transparent container during a registration procedure as specified in 3GPP TS 23.122 Annex C.2, the UE shall suspend the transmission of 5GSM messages after sending the REGISTRATION COMPLETE message and until the N1 NAS signalling connection is released to obtain service on a higher priority PLMN, with the exception of the case when the UE has an emergency PDU session.<br />
<br />
A 5GMM message piggybacking a 5GSM message for a PDU session shall be delivered via the access associated with the PDU session, if any, with the following exceptions:<br />
<ol type="a"><br />
<li>the AMF shall send, via 3GPP access, a Downlink (DL) NAS TRANSPORT message piggybacking a downlink 5GSM message of a network-requested 5GSM procedure for a PDU session associated with non-3GPP access if the conditions specified in subclause 5.5.1.3.4 or subclause 5.6.1.4 are met;</li><br />
<li>the UE shall send an UL NAS TRANSPORT message piggybacking a response message to the 5GSM message described in a) via either:</li><br />
# 3GPP access; or<br />
# non-3GPP access if the UE is in 5GMM-CONNECTED mode over non-3GPP access; and<br />
:NOTE: The interaction between the 5GMM sublayer and the 5GSM sublayer to enable the UE to send the UL NAS TRANSPORT message containing the response message via 3GPP access is required. This is achieved via UE implementation.<br />
<li>the UE shall send, via the target access, an Uplink (UL) NAS TRANSPORT message piggybacking a 5GSM message associated with a request type set to "existing PDU session" or "existing emergency PDU session" for handover of an existing PDU session between 3GPP access and non-3GPP access.</li><br />
</ol><br />
<br />
A 5GMM message piggybacking a 5GSM message as a response message to a request message associated with an MA PDU session, shall be delivered via the same access that the initial message was received.<br />
<br />
== UE domain selection ==<br />
<br />
See spec<br />
<br />
== 4.4 NAS security ==<br />
<br />
=== 4.4.1 General ===<br />
This clause describes the principles for the handling of 5G NAS security contexts in the UE and in the AMF, the procedures used for the <span style="color:blue">security protection of NAS messages between the UE and the AMF</span>, and the procedures used for the <span style="color:blue">protection of NAS IEs between the UE and the UDM</span>. Security protection involves integrity protection and ciphering of the 5GMM messages. 5GSM messages are security protected indirectly by being piggybacked by the security protected 5GMM messages (i.e. UL NAS TRANSPORT message and the DL NAS TRANSPORT message).<br />
<br />
The signalling procedures for the control of NAS security are part of the 5GMM protocol and are described in detail in clause 5.<br />
<br />
<span style="color:green">NOTE ''The use of ciphering in a network is an operator option.'' In this subclause, for the ease of description, it is assumed that ciphering is used, unless explicitly indicated otherwise. Operation of a network without ciphering is achieved by configuring the AMF so that it always selects the "null ciphering algorithm", 5G-EA0.</span><br />
<br />
=== 4.4.2 Handling of 5G NAS security contexts ===<br />
<br />
==== 4.4.2.5 Establishment of secure exchange of NAS messages ====<br />
Secure exchange of NAS messages via a NAS signalling connection is <span style="color:red">usually established by the AMF during the registration procedure by initiating a security mode control procedure</span>. After successful completion of the security mode control procedure, all NAS messages exchanged between the UE and the AMF are sent integrity protected using the current 5G security algorithms, and <span style="color:red">except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered</span> using the current 5G security algorithms.<br />
<br />
==== 4.4.4.2 Integrity checking of NAS signalling messages in the UE ====<br />
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the UE or forwarded to the 5GSM entity, unless the network has established secure exchange of 5GS NAS messages for the NAS signalling connection:<br />
<ol type="a"><br />
<li>IDENTITY REQUEST (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION REQUEST;</li><br />
<li>AUTHENTICATION RESULT;</li><br />
<li>AUTHENTICATION REJECT;</li><br />
<li>REGISTRATION REJECT (if the 5GMM cause is not #76 or #78);</li><br />
<li>DEREGISTRATION ACCEPT (for non switch off); and</li><br />
<li>SERVICE REJECT (if the 5GMM cause is not #76 or #78).</li><br />
</ol><br />
:NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.<br />
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once the secure exchange of NAS messages has been established, the receiving 5GMM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. The processing of the SECURITY MODE COMMAND message that has not successfully passed the integrity check is specified in subclause 5.4.2.5. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.<br />
<br />
==== 4.4.4.3 Integrity checking of NAS signalling messages in the AMF ====<br />
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the AMF or forwarded to the 5GSM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:<br />
<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST;</li><br />
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION RESPONSE;</li><br />
<li>AUTHENTICATION FAILURE;</li><br />
<li>SECURITY MODE REJECT;</li><br />
<li>DEREGISTRATION REQUEST; and</li><br />
<li>DEREGISTRATION ACCEPT;</li><br />
</ol><br />
<br />
:NOTE 1: The REGISTRATION REQUEST message is sent by the UE without integrity protection, if the registration procedure is initiated due to an inter-system change in 5GMM-IDLE mode and no current 5G NAS security context is available in the UE. The other messages are accepted by the AMF without integrity protection, as in certain situations they are sent by the UE before security can be activated.<br />
<br />
:NOTE 2: The DEREGISTRATION REQUEST message can be sent by the UE without integrity protection, e.g. if the UE is registered for emergency services and there is no valid 5G NAS security context available, or if due to user interaction a registration procedure is cancelled before the secure exchange of NAS messages has been established. For these cases the network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.<br />
<br />
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once a current 5G NAS security context exists, until the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF shall process the following NAS signalling messages, even if the MAC included in the message fails the integrity check or cannot be verified, as the 5G NAS security context is not available in the network:<br />
<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST;</li><br />
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION RESPONSE;</li><br />
<li>AUTHENTICATION FAILURE;</li><br />
<li>SECURITY MODE REJECT;</li><br />
<li>DEREGISTRATION REQUEST;</li><br />
<li>DEREGISTRATION ACCEPT;</li><br />
<li>SERVICE REQUEST; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST;</li><br />
</ol><br />
<br />
:NOTE 3: These messages are processed by the AMF even when the MAC that fails the integrity check or cannot be verified, as in certain situations they can be sent by the UE protected with a 5G NAS security context that is no longer available in the network.<br />
<br />
If a REGISTRATION REQUEST message for initial registration fails the integrity check and it is not a registration request for emergency services, the AMF shall authenticate the subscriber before processing the registration request any further. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the registration procedure is for emergency services see subclause 5.5.1.2.3 and subclause 5.4.1.3.5.<br />
<br />
If a REGISTRATION REQUEST message for mobility and periodic registration update fails the integrity check and the UE provided EPS NAS message container IE which was successfully verified by the source MME, the AMF may create a mapped 5G NAS security context and initiate a security mode control procedure to take the new mapped 5G NAS security context into use; otherwise if the UE has only a non-emergency PDU session established, the AMF shall initiate a primary authentication and key agreement procedure to create a new native 5G NAS security context. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the UE has an emergency PDU session see subclause 5.5.1.3.3 and subclause 5.4.1.3.5.<br />
<br />
If a DEREGISTRATION REQUEST message fails the integrity check, the AMF shall proceed as follows:<br />
:- If it is not a deregistration request due to switch off, and the AMF can initiate an authentication procedure, the AMF should authenticate the subscriber before processing the deregistration request any further.<br />
:- If it is a deregistration request due to switch off, or the AMF does not initiate an authentication procedure for any other reason, the AMF may ignore the deregistration request and remain in state 5GMM-REGISTERED.<br />
:NOTE 4: The network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.<br />
<br />
If a SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message fails the integrity check and the UE has only non-emergency PDU sessions established, the AMF shall send the SERVICE REJECT message with 5GMM cause #9 "UE identity cannot be derived by the network" and keep the 5GMM-context and 5G NAS security context unchanged. For the case when the UE has an emergency PDU session and integrity check fails, the AMF may skip the authentication procedure even if no 5G NAS security context is available and proceed directly to the execution of the security mode control procedure as specified in subclause 5.4.2. Additionally, the AMF shall include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. After successful completion of the service request procedure, the network shall perform a local release of all non-emergency PDU sessions. The emergency PDU sessions shall not be released.<br />
<br />
Once the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If any NAS signalling message, having not successfully passed the integrity check, is received, then the NAS in the AMF shall discard that message. If any NAS signalling message is received, as not integrity protected even though the secure exchange of NAS messages has been established, then the NAS shall discard this message.<br />
<br />
=== 4.4.5 Ciphering of NAS signalling messages ===<br />
<span style="color:red">'''The use of ciphering in a network is an operator option subject to AMF configuration'''</span>. <span style="color:red">When operation of the network without ciphering is configured, the AMF shall indicate the use of "null ciphering algorithm" 5G-EA0 (see subclause 9.11.3.34) in the current 5G NAS security context for all UEs</span>. For setting the security header type in outbound NAS messages, the UE and the AMF shall apply the same rules irrespective of whether the "null ciphering algorithm" or any other ciphering algorithm is indicated in the 5G NAS security context.<br />
<br />
<span style="color:red">When the UE establishes a new N1 NAS signalling connection, it shall apply security protection to the initial NAS message as described in subclause 4.4.6.<br />
</span><br />
The UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has been established for an N1 NAS signalling connection. From this time onward, unless explicitly defined, the UE shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.<br />
<br />
The AMF shall start ciphering and deciphering of NAS messages as described in subclause 4.4.2.5. From this time onward, except for the SECURITY MODE COMMAND message, the AMF shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.<br />
<br />
Ciphering is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once the encryption of NAS messages has been started between the AMF and the UE, the receiver shall discard the unciphered NAS messages which shall have been ciphered according to the rules described in this specification.<br />
If the "null ciphering algorithm" 5G-EA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered.<br />
Details of ciphering and deciphering of NAS signalling messages are specified in 3GPP TS 33.501.<br />
<br />
=== 4.4.6 Protection of initial NAS signalling messages ===<br />
The 5GS supports protection of initial NAS messages as specified in 3GPP TS 33.501. <span style="color:red">The protection of initial NAS messages applies to the REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST message</span>, and is achieved as follows:<br />
<ol type="a"><li><span style="color:red">If the UE does not have a valid 5G NAS security context, the UE sends a REGISTRATION REQUEST message including cleartext IEs only.</span> After activating a 5G NAS security context resulting from a security mode control procedure:<br />
<ol><br />
<li>if the UE needs to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message; or</li><br />
<li>if the UE does not need to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs only) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message.</li></ol></li><br />
<li>If the UE has a valid 5G NAS security context and:<br />
<ol><br />
<li>the UE needs to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE includes the entire REGISTRATION REQUEST or SERVICE REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a REGISTRATION REQUEST or SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li><br />
<li>the UE needs to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message:</li><br />
<ol type="i"><br />
:<li>if CIoT small data container IE is the only non-cleartext IE to be sent, the UE shall cipher the value part of the CIoT small data container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the CIoT small data container IE;</li><br />
:<li>otherwise, the UE includes non-cleartext IEs in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li></ol><br />
<li>the UE does not need to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE sends the REGISTRATION REQUEST or SERVICE REQUEST message without including the NAS message container IE; or</li><br />
<li>the UE does not need to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message, the UE sends the CONTROL PLANE SERVICE REQUEST message without including the NAS message container IE and the CIoT small data container IE.</li><br />
</ol><br />
</ol><br />
<span style="color:red">When the initial NAS message is a REGISTRATION REQUEST message, the cleartext IEs are</span>:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* Registration request message identity;<br />
* 5GS registration type;<br />
* ngKSI;<br />
* <span style="color:red">5GS mobile identity</span>;<br />
* UE security capability;<br />
* Additional GUTI;<br />
* UE status;<br />
* EPS NAS message container;<br />
* NID; and<br />
* PLMN with disaster condition.<br />
<br />
When the initial NAS message is a SERVICE REQUEST message, the cleartext IEs are:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* ngKSI;<br />
* Service request message identity;<br />
* Service type; and<br />
* <span style="color:red">5G-S-TMSI</span>.<br />
<br />
When the initial NAS message is a CONTROL PLANE SERVICE REQUEST message, the cleartext IEs are:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* ngKSI;<br />
* Control plane service request message identity; and<br />
* Control plane service type.<br />
<br />
When the UE sends a REGISTRATION REQUEST or SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message that includes a NAS message container IE, the UE shall set the security header type of the initial NAS message to "integrity protected".<br />
<br />
When the AMF receives an integrity protected initial NAS message which includes a NAS message container IE, the AMF shall decipher the value part of the NAS message container IE. If the received initial NAS message is a REGISTRATION REQUEST message or a SERVICE REQUEST message, the AMF shall consider the NAS message that is obtained from the NAS message container IE as the initial NAS message that triggered the procedure.<br />
<br />
When the AMF receives a CONTROL PLANE SERVICE REQUEST message which includes a CIoT small data container IE, the AMF shall decipher the value part of the CIoT small data container IE and handle the message as specified in subclause 5.6.1.4.2.<br />
<br />
When the initial NAS message is a DEREGISTRATION REQUEST message, the UE always sends the NAS message unciphered.<br />
<br />
If the UE:<br />
<ol type="a"><br />
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li><br />
<li>selects a PLMN other than Registered PLMN and EPLMN over one access;</li><br />
</ol><br />
the UE shall send an initial NAS message including cleartext IEs only via the access type associated with the newly selected PLMN as described in this subclause for the case when the UE does not have a valid 5G NAS security context.<br />
<br />
If the UE:<br />
<ol type="a"><br />
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li><br />
<li>selects a PLMN other than Registered PLMN and EPLMN over one access, and the Registered PLMN or EPLMN is not registering or registered over other access;</li><br />
</ol><br />
the UE shall delete the 5G NAS security context.<br />
<br />
:NOTE: UE deletes the 5G NAS security context only if the UE is not in the connected mode.<br />
<br />
=== 4.4.7 Protection of NAS IEs ===<br />
The network can provide the Steering of Roaming (SOR) transparent container Information Element (IE) during the registration procedure to the User Equipment (UE) in the REGISTRATION ACCEPT message. The SOR transparent container IE is integrity protected by the Home Public Land Mobile Network (HPLMN) or subscribed Standalone Non-Public Network (SNPN) as specified in 3GPP TS 33.501.<br />
<br />
The UE can provide the SOR transparent container IE during the registration procedure to the network in the REGISTRATION COMPLETE message. The SoR-MAC-IUE in the SOR transparent container IE is generated by the UE as specified in 3GPP TS 33.501.<br />
<br />
The network can provide the Payload container IE during the Network-initiated NAS transport procedure to the UE in DL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the Payload container IE is integrity protected by the HPLMN or subscribed SNPN as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the payload container entry contents field of the payload container entry is integrity protected correspondingly.<br />
<br />
The UE can provide the Payload container IE during the UE-initiated NAS transport procedure to the network in UL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the Payload container IE is generated by the UE as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the payload container entry contents field of the payload container entry is generated by the UE correspondingly.<br />
<br />
== 4.7 NAS over non-3GPP access ==<br />
<br />
See spec for details<br />
<br />
=== 4.7.1 General ===<br />
From the UE's NAS perspective, in general the procedures and messages defined for 5GMM and 5GSM are used over non-3GPP access as over 3GPP access. However, a number of aspects are different as described in the following subclauses.<br />
<br />
=== 4.7.2 5GS mobility management (5GMM) aspects ===<br />
<br />
==== 4.7.2.1 General ====<br />
The mobility management procedures defined over 3GPP access are re-used over non-3GPP access with certain exceptions. The list goes from a) to s), see spec for details.<br />
<br />
==== 4.7.2.2 Establishment cause for non-3GPP access ====<br />
When establishment of an N1 NAS signalling connection over non-3GPP access is initiated, the UE shall do certain things. See spec for details.<br />
<br />
<br />
=== 4.7.3 5GS session management (5GSM) aspects ===<br />
The session management procedures defined over 3GPP access are re-used over non-3GPP access with the following exceptions:<br />
<ol type="a"><br />
<li>Serving PLMN rate control does not apply for non-3GPP access;</li><br />
<li>Small data rate control does not apply for non-3GPP access;</li><br />
<li>Handling of 5GSM cause value #82 "maximum data rate per UE for user-plane integrity protection is too low" does not apply for non-3GPP access;</li><br />
<li>MBS does not apply for non-3GPP access; and</li><br />
<li>Support of redundant PDU sessions does not apply for non-3GPP access.</li><br />
</ol><br />
<br />
=== 4.7.4 Limited service state over non-3GPP access ===<br />
<br />
There are a number of situations in which the UE is unable to obtain normal service from a PLMN over non-3GPP access and the UE enters the limited service state over non-3GPP access. These include:<br />
<ol type="a"><br />
<li>no Universal Subscriber Identity Module (USIM) in the Mobile Equipment (ME);</li><br />
<li>an "illegal UE" or "illegal ME" is received when registration, network-initiated de-registration or service request is performed (any USIM in the ME is then considered "invalid");</li><br />
<li>a "5GS services not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "PLMN not allowed" is received when registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "Tracking area not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "Roaming not allowed in this tracking area" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>void; or</li><br />
<li>a "Serving network not authorized" is received when a registration or service request is performed.</li><br />
</ol><br />
In limited service state with a valid USIM in the UE, the network selection is performed as defined in 3GPP TS 24.502.<br />
<br />
With the exception of performing initial registration for emergency services, no registration requests are made until a valid USIM is present. For registration for emergency services, the PLMN of the current N3IWF or TNGF is considered as the selected PLMN for the duration the UE is registered for emergency services.<br />
<br />
=== 4.7.5 NAS signalling using trusted WLAN access network ===<br />
<br />
A trusted WLAN interworking function (TWIF) provides functionalities for a non-5G capable over WLAN (N5CW) device to access 5GCN, including:<br />
<ol type="a"><br />
<li>NAS signalling over N1 NAS signalling connection with AMF; and</li><br />
<li>PDU session establishment, modification and release on behalf of the N5CW device, over N2 connection with the AMF.</li><br />
</ol><br />
The TWIF registers on behalf of the N5CW device to an AMF according to subclause 5.5.1.3 by populating the parameters for the registration by using implementation specific default values which are the same for N5CW devices.<br />
<br />
The TWIF may request to establish a PDU session as specified in subclause 6.4.1.2 on behalf of the N5CW device upon receipt of an IP configuration request from the N5CW device by populating either all the required parameters or part of the required parameters for the PDU session establishment by using implementation specific default values from the TWIF's configuration. Only one PDU session is supported when N5CW device accessing 5GC via the TWIF.<br />
<br />
:NOTE 1: If part of the required parameters for the PDU session establishment is provided by the TWIF, the remaining of the required parameters are determined by the AMF or the SMF based on the N5CW device's subscription information.<br />
Upon loss of the IP address of the N5CW device, the TWIF acting on behalf of the N5CW device shall initiate the UE-requested PDU session release procedure as defined in subclause 6.4.3.<br />
<br />
:NOTE 2: The established PDU session on behalf of the N5CW device can be modified by the TWIF or the network.<br />
<br />
== 4.8 Interworking with E-UTRAN connected to EPC ==<br />
<br />
=== 4.8.1 General ===<br />
In order to interwork with E-UTRAN connected to EPC, the UE supporting both S1 mode and N1 mode can operate in single-registration mode or dual-registration mode (see 3GPP TS 23.501). Support of single-registration mode is mandatory for UEs supporting both S1 mode and N1 mode.<br />
<br />
During the EPS attach procedure (see 3GPP TS 24.301) or initial registration procedure (see subclause 5.5.1.2), the mode for interworking is selected if the UE supports both S1 mode and N1 mode, and the network supports interworking. The mode for interworking may also be selected during the EPS tracking area updating procedure (see 3GPP TS 24.301) or registration procedure for mobility and periodic registration update (see subclause 5.5.1.3).<br />
<br />
For interworking between E-UTRAN connected to EPC and TNGF or N3IWF connected to 5GCN, the UE shall operate as specified in either subclause 4.8.2.3 or subclause 4.8.3. Which subclause the UE follows is chosen by the UE irrespective of the interworking without N26 interface indicator.<br />
<br />
=== 4.8.2 Single-registration mode ===<br />
See spec for details...<br />
<br />
=== 4.8.3 Dual-registration mode ===<br />
<br />
If both 5G Mobility Management (5GMM) and EPS Mobility Management (EMM) are enabled, a UE, operating in the dual-registration mode shall maintain independent contexts for 5GMM and EMM and this includes independent lists of equivalent PLMNs. Coordination between 5GMM and EMM is not needed, except as specified in the present subclause, subclause 5.1.5 and 5.3.13A.<br />
<br />
For dual-registration mode the following applies:<br />
<ol type="a"><br />
<li>a UE operating in the dual-registration mode may register to N1 mode only, S1 mode only, or to both N1 mode and S1 mode;</li><br />
<li>when the UE decides to operate in dual-registration mode (see subclause 5.5.1.2.4), NAS informs the lower layers about this;</li><br />
<li>if a UE is registered in N1 mode only, then for registration in S1 mode the UE shall use:</li><br />
# the same PLMN to which it is registered in N1 mode; or<br />
# an equivalent PLMN; and<br />
<li>if a UE is registered in S1 mode only, then for registration in N1 mode the UE shall use:</li><br />
# the same PLMN to which it is registered in S1 mode; or<br />
# an equivalent PLMN.<br />
</ol><br />
:NOTE 1: It is up to UE implementation how to handle the case when the UE is registered in both N1 mode and S1 mode and the PLMNs to which the UE is registered, are not equivalent, e.g. search for a PLMN which is the same or equivalent to any of the registered ones.<br />
<br />
When no PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure with PDN connection establishment if EMM-REGISTERED without PDN connection is not supported by the MME. If EMM-REGISTERED without PDN connection is supported by the MME, the UE may initiate either the EPS attach procedure without PDN connection establishment or the attach procedure with PDN connection establishment.<br />
<br />
When at least one PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure. If necessary, the UE may transfer an active PDU session from N1 mode to S1 mode by initiating the EPS attach procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message. After successfully attached in S1 mode, if necessary, the UE may transfer other active PDU sessions from N1 mode to S1 mode by initiating the PDN connectivity procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message.<br />
<br />
:NOTE 2: It is up to UE implementation to determine which active PDU session is transferred from N1 mode to S1 mode.<br />
<br />
When the UE has not registered to N1 mode, the UE may initiate the initial registration procedure. After successfully registered in N1 mode, if necessary, the UE may transfer one or more active PDN connections from S1 mode to N1 mode by initiating the PDU session establishment procedure with request type set to "existing PDU session".<br />
<br />
:NOTE 3: It is up to UE implementation to determine which active PDN connection is transferred from S1 mode to N1 mode.<br />
<br />
If the MME supports EMM-REGISTERED without PDN connection, the UE that transferred all PDN connections to the 5GS, may stay in state EMM-REGISTERED. Otherwise, the UE shall enter state EMM-DEREGISTERED upon transferring all PDN connection to the 5GS.<br />
<br />
:NOTE 4: When the UE has registered in both N1 mode and S1 mode, it is up to UE implementation to maintain the registration update to date in both N1 mode and S1 mode.<br />
<br />
See subclause 6.1.4 for coordination between 5GSM and ESM.<br />
<br />
See subclause 4.8.2.3.2 for interworking between TNGF or N3IWF connected to 5GCN and E-UTRAN.<br />
<br />
=== 4.8.4 Core Network selection for UEs not using Cellular Internet of Things (CIoT) 5GS optimizations ===<br />
If the UE is capable of both N1 mode and S1 mode, when the UE needs to use one or more functionalities not supported in 5GS but supported in EPS and the UE is in 5GMM-IDLE mode, the UE may disable the N1 mode capability for 3GPP access (see subclause 4.9.2).<br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN without also providing an indication that a target core network type was received from the NG-RAN, the UE shall select a core network type (EPC or 5GCN) based on the PLMN selection procedures as specified in 3GPP TS 23.122 and provide the selected core network type information to the lower layer during the initial registration procedure.<br />
<br />
If the UE is capable of both N1 mode and S1 mode and the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN and an indication of whether the network supports IMS emergency services via either EPC or 5GCN or both (see 3GPP TS 36.331 [25A]), the UE selects a core network type (EPC or 5GCN) as specified in 3GPP TS 23.167 [6] annex H.2 for initiating emergency calls when in the state 5GMM-DEREGISTERED.LIMITED-SERVICE or EMM-DEREGISTERED.LIMITED-SERVICE.<br />
:NOTE 1: If the PLMN selection information provisioned in the USIM does not contain any prioritization between E-UTRAN and NG-RAN for a PLMN, which core network type to select for that PLMN is up to UE implementation.<br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN with:<br />
# an indication that target core network type EPC was received from the NG-RAN, the UE shall select the EPC and proceed with the appropriate EMM procedure as specified in 3GPP TS 24.301; or<br />
# an indication that target core network type 5GCN was received from the NG-RAN, the UE shall select the 5GCN and proceed with the appropriate 5GMM procedure.<br />
:NOTE 2: The NG-RAN can provide a target core network type to the UE during RRC connection release with redirection (see 3GPP TS 36.331 and 3GPP TS 38.331).<br />
<br />
=== 4.8.4A Core Network selection and redirection for UEs using CIoT optimizations ===<br />
<br />
==== 4.8.4A.1 Core network selection ====<br />
A UE that supports CIoT optimizations performs core network selection (i.e. it selects EPC or 5GCN) if the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN as specified in 3GPP TS 23.501.<br />
<br />
When selecting a PLMN as described in 3GPP TS 23.122, the UE shall select a core network type (EPC or 5GCN) based on:<br />
<ol type="a"><br />
<li>indication from the lower layers about the CIoT EPS optimizations supported in EPC;</li><br />
<li>indication from the lower layers about the CIoT 5GS optimizations supported in 5GCN;</li><br />
<li>the CIoT EPS optimizations supported by the UE;</li><br />
<li>the CIoT 5GS optimizations supported by the UE;</li><br />
<li>the UE's preferred CIoT network behaviour for EPC; and</li><br />
<li>the UE's preferred CIoT network behaviour for 5GCN.</li><br />
</ol><br />
<br />
The UE shall provide the selected core network type information to the lower layer during the initial registration procedure.<br />
<br />
==== 4.8.4A.2 Redirection of the UE by the core network ====<br />
The network that supports CIoT optimizations can redirect a UE between EPC and 5GCN as specified in subclause 5.31.3 of 3GPP TS 23.501. The network can take into account the UE's N1 mode capability or S1 mode capability, the CIoT network behaviour supported and preferred by the UE or the CIoT network behaviour supported by the network to determine the redirection.<br />
<br />
:NOTE: It is assumed that the network would avoid redirecting the UE back and forth between EPC and 5GCN.<br />
<br />
The network redirects the UE to EPC by rejecting the registration request or service request with the 5GMM cause #31 "Redirection to EPC required" as specified in subclause 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5. Upon receipt of reject message, the UE disables the N1 mode capability for 3GPP access as specified in subclause 4.9.2 and enables the E-UTRA capability if it was disabled in order to move to EPC.<br />
<br />
When there is no ongoing registration procedure or service request procedure for a UE in 5GMM-CONNECTED mode, if the AMF determines to redirect the UE to EPC, the AMF shall initiate the generic UE configuration update procedure to indicate registration requested and release of the N1 NAS signalling connection not requested as described in subclause 5.4.4. The network then redirects the UE to EPC by rejecting the registration request as specified in subclause 5.5.1.3.5.<br />
<br />
The network that supports CIoT optimizations can also redirect a UE from EPC to 5GCN as specified in subclause 5.3.19.2 of 3GPP TS 24.301.<br />
<br />
== 4.9 Disabling and re-enabling of UE's N1 mode capability ==<br />
<br />
=== 4.9.1 General ===<br />
<br />
The UE shall re-enable the N1 mode capability when the UE powers off and powers on again, the USIM is removed or an entry of the "list of subscriber data" with the SNPN identity of the SNPN is updated.<br />
<br />
=== 4.9.2 Disabling and re-enabling of UE's N1 mode capability for 3GPP access ===<br />
<br />
The UE shall only disable the N1 mode capability for 3GPP access when in 5GMM-IDLE mode.<br />
<br />
When the UE is disabling the N1 mode capability for 3GPP access for a PLMN not due to redirection to EPC, it should proceed as follows:<br />
<ol type="a"><br />
<li>select an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs, if the UE supports S1 mode and the UE has not disabled its E-UTRA capability as specified in 3GPP TS 24.301;</li><br />
<li>if an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, the UE does not support S1 mode or the UE has disabled its E-UTRA capability as specified in 3GPP TS 24.301, the UE may select another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs that the UE supports;</li><br />
<li>if another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, then enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH, or the UE does not have a registered PLMN, then enter the state 5GMM-DEREGISTERED.PLMN-SEARCH and perform PLMN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this PLMN selection. As an implementation option, if the UE does not have a registered PLMN, instead of performing PLMN selection, the UE may select another RAT of the selected PLMN if the UE has chosen a PLMN and the RAT is supported by the UE; or</li><br />
<li>if no other allowed PLMN and RAT combinations are available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered PLMN, and may periodically scan for another PLMN and RAT combination which can provide EPS services or non-EPS services (if the UE supports EPS services or non-EPS services). How this periodic scanning is done, is UE implementation dependent.</li><br />
</ol><br />
When the UE is disabling the N1 mode capability for 3GPP access for an SNPN, it should proceed as follows:<br />
<ol type="a"><br />
<li>enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH and perform SNPN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this SNPN selection; or</li><br />
<li>if no other SNPN is available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered SNPN.</li><br />
</ol><br />
<br />
When the UE is disabling the N1 mode capability upon receiving cause value #31 "Redirection to EPC required" as specified in subclauses 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5, it should proceed as follows:<br />
<ol type="a"><br />
<li>If the UE is in NB-N1 mode:</li><br />
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable NB-IoT cell connected to EPC according to 3GPP TS 36.304;<br />
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or<br />
# if lower layers cannot find a suitable NB-IoT cell connected to EPC or there is no suitable NB-IoT cell connected to EPC which supports CIoT EPS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.<br />
<li>If the UE is in WB-N1 mode:</li><br />
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable E-UTRA cell connected to EPC according to 3GPP TS 36.304;<br />
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, then perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or<br />
# if lower layers cannot find a suitable E-UTRA cell connected to EPC or there is no suitable E-UTRA cell connected to EPC which supports CIoT EPS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.<br />
</ol><br />
<br />
When the UE supporting both N1 mode and S1 mode needs to stay in E-UTRA connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional handover or cell reselection from E-UTRA connected to EPC to NG-RAN connected to 5GCN, the UE operating in single-registration mode shall disable the N1 mode capability for 3GPP access and:<br />
<ol type="a"><br />
<li>shall set the N1mode bit to "N1 mode for 3GPP access not supported" in the UE network capability IE (see 3GPP TS 24.301) of the ATTACH REQUEST message and the TRACKING AREA UPDATE REQUEST message in EPC; and</li><br />
<li>the UE NAS layer shall indicate the access stratum layer(s) of disabling of the N1 mode capability for 3GPP access.</li><br />
</ol><br />
<br />
If the UE is required to disable the N1 mode capability for 3GPP access and select E-UTRA or another RAT, and the UE is in the 5GMM-CONNECTED mode,<br />
* if the UE has a persistent PDU session, then the UE waits until the radio bearer associated with the persistent PDU session has been released;<br />
* otherwise the UE shall locally release the established NAS signalling connection;<br />
<br />
and enter the 5GMM-IDLE mode before selecting E-UTRA or another RAT.<br />
<br />
If the UE is disabling its N1 mode capability for 3GPP access before selecting E-UTRA or another RAT, the UE shall not perform the UE-initiated de-registration procedure of subclause 5.5.2.2.<br />
<br />
The UE shall re-enable the N1 mode capability for 3GPP access when the UE performs PLMN or SNPN selection over 3GPP access, unless<br />
* disabling of the N1 mode capability for 3GPP access was due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off; or<br />
* the UE has already re-enabled the N1 mode capability for 3GPP access when performing items c) or d) above.<br />
<br />
If the disabling of N1 mode capability for 3GPP access was due to IMS voice is not available over 3GPP access and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for 3GPP access when the UE's usage setting is changed from "voice centric" to "data centric", as specified in subclauses 4.3.3.<br />
<br />
The UE should memorize the identity of the PLMN or SNPN where N1 mode capability for 3GPP access was disabled and should use that stored information in subsequent PLMN or SNPN selections as specified in 3GPP TS 23.122.<br />
<br />
If the disabling of N1 mode capability for 3GPP access was due to successful completion of an emergency services fallback, the criteria to enable the N1 mode capability again are UE implementation specific.<br />
<br />
The UE shall disable the N1 mode capability for 3GPP access if requested by the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229). If the UE disabled the N1 mode capability for 3GPP access based on the request from the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229), the criteria to re-enable the N1 mode capability for 3GPP access after the completion of an emergency service are UE implementation specific.<br />
<br />
If the N1 mode capability for 3GPP access was disabled due to the UE initiated de-registration procedure for 3GPP access or for 3GPP access and non-3GPP access and the UE is operating in single-registration mode (see subclause 5.5.2.2.3), upon request of the upper layers to re-register for 5GS services over 3GPP access the UE shall enable the N1 mode capability for 3GPP access again.<br />
<br />
As an implementation option, the UE may start a timer for enabling the N1 mode capability for 3GPP access when the UE's registration attempt counter reaches 5 and the UE disables the N1 mode capability for 3GPP access for cases described in subclauses 5.5.1.2.7 and 5.5.1.3.7. The UE should memorize the identity of the PLMNs where N1 mode capability for 3GPP access was disabled. On expiry of this timer:<br />
* if the UE is in Iu mode or A/Gb mode and is in idle mode as specified in 3GPP TS 24.008 on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access;<br />
* if the UE is in Iu mode and a PS signalling connection exists, but no RR connection exists, the UE may abort the PS signalling connection before enabling the N1 mode capability for 3GPP access; and<br />
* if the UE is in S1 mode and is in EMM-IDLE mode as specified in 3GPP TS 24.301, on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access.<br />
<br />
If the UE is in Iu mode or A/Gb mode and an Radio Resource (RR) connection exists, the UE should delay enabling the N1 mode capability for 3GPP access until the RR connection is released. If the UE is in S1 mode and is in EMM-CONNECTED mode as specified in 3GPP TS 24.301, the UE should delay enabling the N1 mode capability for 3GPP access until the NAS signalling connection in S1 mode is released.<br />
<br />
<pre>A Interface between a BSS and a 2G MSC<br />
Gb Interface between a BSS and a 2G SGSN<br />
Iu-cs Interface between a BSS and a 3G MSC<br />
Iu-ps Interface between a BSS and a 3G SGSN<br />
Iur-g Interface between two BSSs<br />
Um Interface between MS and BSS<br />
<br />
Source: 3GPP TS 43.501</pre><br />
<br />
The UE may disable the N1 mode capability for currently camped PLMN or SNPN over 3GPP access (see 3GPP TS 23.122) if no network slice is available for the camped PLMN or SNPN.<br />
<br />
If the UE attempts to establish an emergency PDU session in a PLMN where N1 mode capability was disabled due to the UE's registration attempt counter have reached 5, the UE may enable N1 mode capability for that PLMN memorized by the UE.<br />
<br />
:NOTE: If N1 mode capability is disabled due to the UE's registration attempt counter reaches 5, the value of the timer for re-enabling N1 mode capability is recommended to be the same as the value of T3502 which follows the handling specified in subclause 5.3.8.<br />
<br />
=== 4.9.3 Disabling and re-enabling of UE's N1 mode capability for non-3GPP access ===<br />
<br />
When the UE disables the N1 mode capability for non-3GPP access, the UE NAS layer shall not initiate any 5GS NAS procedures towards the network over non-3GPP access.<br />
<br />
When the UE supporting both N1 mode and S1 mode needs to stay in non-3GPP access connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional selection of a non-3GPP access network connected to 5GCN, the UE operating in single-registration mode shall not transfer any PDN connection to a non-3GPP access network connected to the 5GCN.<br />
<br />
If the disabling of N1 mode capability for non-3GPP access was due to IMS voice is not available over non-3GPP access in 5GS and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for non-3GPP access when the UE's usage setting is changed from "voice centric" to "data centric" as specified in subclauses 4.3.3.<br />
<br />
The UE shall re-enable the N1 mode capability for non-3GPP access when a new PLMN or SNPN is selected over non-3GPP access.<br />
<br />
:NOTE: In SNPN, the term "UE's N1 mode capability for non-3GPP access" in this subclause refers to the UE's N1 mode capability to access SNPN services via a PLMN.<br />
<br />
The UE may disable the N1 mode capability for the currently camped PLMN or SNPN over non-3GPP access if no network slice is available for the camped PLMN or SNPN.<br />
<br />
As an implementation option, the UE may start a timer for re-enabling the N1 mode capability for non-3GPP access, after the N1 mode capability for non-3GPP access was disabled. On the expiry of this timer, the UE should re-enable the N1 mode capability for non-3GPP access.<br />
<br />
== 4.11 UE configuration parameter updates ==<br />
<br />
The 5GS in a PLMN supports updating UE parameters via NAS signalling. The feature enables the HPLMN to securely and dynamically re-configure the UE configuration parameters stored on the USIM and the ME.<br />
<br />
See spec for details...<br />
<br />
== 4.13 Support of NAS signalling using wireline access network ==<br />
A 5G-RG, a W-AGF acting on behalf of an FN-RG or a W-AGF acting on behalf of an N5GC device can use wireline access network to access the 5GCN by using NAS signalling procedures as described in 3GPP TS 23.501, 3GPP TS 23.502 and 3GPP TS 23.316.<br />
<br />
Wireline access is a type of non-3GPP access.<br />
<br />
A 5G-RG simultaneously connected to the same 5GCN of a PLMN over a 3GPP access and a wireline access is connected to a single AMF.<br />
<br />
5G-RG maintains the N1 NAS signalling connection with the AMF over the wireline access network after all the PDU sessions for the 5G-RG over that access have been released or handed over to 3GPP access.<br />
<br />
See spec for details...<br />
<br />
== 4.14 Non-public network (NPN) ==<br />
=== 4.14.1 General ===<br />
Two types of NPN can be deployed using 5GS: SNPN (see subclause 4.14.2) and PNI-NPN (see subclause 4.14.3).<br />
<br />
==== 4.14.2 Stand-alone non-public network ====<br />
If the UE is not SNPN enabled, the UE is always considered to be not operating in SNPN access operation mode. If the UE is SNPN enabled, the UE can operate in SNPN access operation mode. Details of activation and deactivation of SNPN access operation mode at the SNPN enabled UE are up to UE implementation.<br />
<br />
The functions and procedures of NAS described in the present document are applicable to an SNPN and an SNPN enabled UE unless indicated otherwise.<br />
<br />
See spec for details...<br />
<br />
=== 4.14.3 Public network integrated non-public network (PNI-NPN) ===<br />
<br />
A PNI-NPN is made available by means of e.g. dedicated DNNs or by one or more S-NSSAIs allocated for it. A CAG can be optionally used in order to prevent UEs not allowed to access a PNI-NPN from accessing the PNI-NPN.<br />
<br />
See spec for details...<br />
<br />
== 4.16 UE radio capability signalling optimization ==<br />
<br />
See spec for details...<br />
<br />
== 4.17 5GS mobility management in NB-N1 mode ==<br />
<br />
See spec for details...<br />
<br />
== 4.19 5GS mobility management in WB-N1 mode for IoT ==<br />
<br />
See spec for details...<br />
<br />
== 4.20 5GS session management in WB-N1 mode for IoT ==<br />
<br />
See spec for details...<br />
<br />
== 4.23 NAS over Non-Terrestrial Network ==<br />
<br />
See spec for details...<br />
<br />
== 4.24 Minimization of service interruption (MINT) ==<br />
<br />
The UE and the network may support Minimization of service interruption (MINT). MINT aims to enable a UE to obtain service from a PLMN offering disaster roaming service when a disaster condition applies to the UE's determined PLMN with disaster condition.<br />
<br />
If the UE supports MINT, the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "list of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range provisioned by the network, if available, are stored in the non-volatile memory in the ME as specified in annex C and are kept when the UE enters 5GMM-DEREGISTERED state. Annex C specifies condition under which the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "lists of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range stored in the ME are deleted.<br />
<br />
See spec for details...<br />
<br />
== 4.25 Support of MUSIM features ==<br />
<pre>MUSIM UE: A UE with multiple valid Universal Subscriber Identity Modules (USIMs), capable of initiating and maintaining simultaneous separate registration states over 3GPP access with PLMN(s) using identities and credentials associated with those USIMs and supporting one or more of the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control (see 3GPP TS 23.501).<br />
<br />
Source: 3GPP TS 24.501</pre><br />
<br />
A network and a MUSIM UE may support one or more of the MUSIM features (i.e. the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control).<br />
<br />
If MUSIM UE supports one or more MUSIM features, the UE indicates support of one or more MUSIM features (except for the paging timing collision control) during the registration procedure. If the UE has indicated support of the N1 NAS signalling connection release or the reject paging request or both and the UE supports the paging restriction, the UE indicates support of the paging restriction.<br />
<br />
If the UE indicates support of one or more MUSIM features and the network decides to accept one or more MUSIM features, the network indicates the support of one or more MUSIM features during the registration procedure. The network only indicates the support of the paging restriction together with the support of either N1 NAS signalling connection release or the reject paging request.<br />
<br />
The network does not indicate support for any MUSIM feature to the UE during the registration for emergency services.<br />
<br />
If a UE stops fulfilling the condition to be considered a MUSIM UE as defined in subclause 3.1, and the UE has negotiated support of one or more MUSIM features, then the UE shall initiate a registration procedure for mobility and periodic registration update to indicate that all the MUSIM features are not supported (except for the paging timing collision control) as specified in subclause 5.5.1.3.<br />
<br />
A MUSIM UE operating in NB-N1 mode or in WB-N1 mode CE mode B does not indicate the support for paging indication for voice services during the registration procedure towards the network.<br />
<br />
== 5.1 Overview ==<br />
<br />
=== 5.1.1 General ===<br />
<br />
The main function of the 5GS mobility management (5GMM) sublayer is to support the identification, security, mobility of a UE as well as generic message transport.<br />
<br />
A further function of the 5GMM sublayer is to provide connection management services to the other sublayer(s).<br />
<br />
:NOTE: In a satellite NG-RAN access, a GNSS fix time in lower layers can delay transmission of an initial UL NAS message by up to 100 seconds (GNSS cold state).<br />
<br />
=== 5.1.2 Types of 5GMM procedures ===<br />
Depending on how they can be initiated, three types of 5GMM procedures can be distinguished:<br />
* 5GMM common procedures<br />
* 5GMM specific procedures<br />
* 5GMM connection management procedures<br />
<br />
Three types of 5GMM procedures broken out...<br />
<br />
<ol type="a"><br />
<li>5GMM common procedures:<br />
<br />
5GMM common procedure can always be initiated when the UE is in 5GMM-CONNECTED mode. The procedures belonging to this type are:</li><br />
<ol type="1"><br />
<li>Initiated by the network:</li><br />
<ol type="i"><br />
<li>network-initiated NAS transport;</li><br />
<li>primary authentication and key agreement;</li><br />
<li>security mode control;</li><br />
<li>generic UE configuration update;</li><br />
<li>identification; and</li><br />
<li>network slice-specific authentication and authorization;</li><br />
</ol><br />
<li>Initiated by the UE:<br />
<br />
:UE-initiated NAS transport.</li><br />
<li>Initiated by the UE or the network and used to report certain error conditions detected upon receipt of 5GMM protocol data:<br />
<br />
:5GMM status.</li><br />
</ol><br />
<li>5GMM specific procedures:<br />
<br />
:At any time only one UE initiated 5GMM specific procedure can be running for each of the access network(s) that the UE is camping in. The procedures belonging to this type are:</li><br />
<ol type="1"><br />
<li>Initiated by the UE and used e.g. to register to the network for 5GS services and establish a 5GMM context, to update the location/parameter(s) of the UE:<br />
<br />
:registration.</li><br />
<li>Initiated by the UE or the network and used to deregister from the network for 5GS services and to release a 5GMM context:<br />
<br />
:de-registration.</li><br />
<li>Initiated by the UE and used to deregister from the network for 5GS services and to release a 5GMM context:<br />
<br />
:eCall inactivity procedure.</li><br />
</ol><br />
<li>5GMM connection management procedures:</li><br />
<ol type="1"><br />
<li>Initiated by the UE and used to establish a secure connection to the network or to request the resource reservation for sending data, or both:<br />
<br />
:service request.<br />
<br />
The service request procedure can only be initiated if no UE initiated 5GMM specific procedure is ongoing for each of the access network(s) that the UE is camping in.</li><br />
<li>Initiated by the network and used to request the establishment of an N1 NAS signalling connection or to request re-establishment of user-plane resources for the PDU session(s) associated with 3GPP access or to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access; not applicable for the non-3GPP access network:<br />
<br />
:paging.</li><br />
<li>Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access or to deliver 5GSM downlink signalling messages associated with non-3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over 3GPP access and in 5GMM-IDLE mode over non-3GPP access; or<br><br><br />
<br />
Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with 3GPP access over 3GPP access or to deliver downlink signalling associated with 3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over non-3GPP access, and when the UE is in 5GMM-IDLE mode over 3GPP access and not in MICO mode:<br />
<br />
:notification.</li><br />
</ol><br />
</ol><br />
<br />
:NOTE 1: In NB-N1 mode, the UE NAS using 5GS services with control plane CIoT 5GS optimization can wait for the lower layers to complete the transmission of the previous UL NAS TRANSPORT messages carrying control plane user data before providing subsequent NAS messages. Other implementations are possible.<br />
<br />
:NOTE 2: When providing NAS messages to the lower layers for transmission, the UE NAS using 5GS services with control plane CIoT 5GS optimization can prioritize sending NAS signalling messages over the UL NAS TRANSPORT messages carrying control plane user data. How the UE performs this prioritization is implementation specific.<br />
<br />
=== 5.1.3 5GMM sublayer states ===<br />
<br />
==== 5.1.3.1 General ====<br />
<br />
In the following subclauses, the 5GS mobility management (5GMM) sublayer of the UE and the network is described by means of different state machines. The 5GMM sublayer states is managed per access type independently, i.e. 3GPP access or non-3GPP access. In subclause 5.1.3.2, the states of the 5GMM sublayer are introduced.<br />
<br />
===== 5.1.3.2.1 5GMM sublayer states in the UE =====<br />
<br />
See spec, lots of info...<br />
<br />
===== 5.1.3.2.2 5GS update status in the UE =====<br />
<br />
In order to describe the detailed UE behaviour, the 5GS update (5U) status pertaining to a specific subscriber is defined.<br />
<br />
If the UE is not operating in SNPN access operation mode (see 3GPP TS 23.501), the 5GS update status is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.<br />
<br />
If the UE is operating in SNPN access operation mode, the 5GS update status for each SNPN whose SNPN identity is included in the "list of subscriber data" configured in the ME (see 3GPP TS 23.122) is stored in the non-volatile memory in the ME as described in annex C.<br />
<br />
The 5GS update status value is changed only after the execution of a registration, network-initiated de-registration, 5GS based primary authentication and key agreement, service request, paging procedure or due to change in the current TAI which does not belong to the current registration area while T3346 is running.<br />
<br />
:5U1: UPDATED<br />
::The last registration attempt was successful.<br />
:5U2: NOT UPDATED<br />
::The last registration or service request attempt failed procedurally, e.g. no response or reject message was received from the AMF.<br />
:5U3: ROAMING NOT ALLOWED<br />
::The last registration, service request, or registration for mobility or periodic registration update attempt was correctly performed, but the answer from the AMF was negative (because of roaming or subscription restrictions).<br />
<br />
===== 5.1.3.2.3 5GMM sublayer states in the network side =====<br />
<br />
There are four 5GMM sublayer states in the network side.<br />
<br />
; 5GMM-DEREGISTERED : In the state 5GMM-DEREGISTERED, no 5GMM context has been established or the 5GMM context is marked as deregistered. The UE is deregistered. The network may answer to an initial registration procedure initiated by the UE. The network may also answer to a de-registration procedure initiated by the UE.<br />
; 5GMM-COMMON-PROCEDURE-INITIATED : The network enters the state 5GMM-COMMON-PROCEDURE-INITIATED, after it has started a common 5GMM procedure and is waiting for a response from the UE.<br />
; 5GMM-REGISTERED : In the state 5GMM-REGISTERED, a 5GMM context has been established. Additionally, one or more PDU session(s) may be established at the network.<br />
; 5GMM-DEREGISTERED-INITIATED : The network enters the state 5GMM-DEREGISTERED-INITIATED after it has started a de-registration procedure and is waiting for a response from the UE.<br />
<br />
=== 5.1.4 Coordination between 5GMM and EMM ===<br />
<br />
==== 5.1.4.1 General ====<br />
If both 5GMM and EMM are enabled, a UE, operating in single-registration mode, shall maintain one common registration for 5GMM for 3GPP access and EMM.<br />
<br />
Coordination between 5GMM for 3GPP access and EMM for a UE, which is capable of N1 mode and S1 mode and operates in dual-registration mode, is not needed, except as specified in subclause 4.8.3.<br />
<br />
The coordination between 5GMM for 3GPP access and EMM in subclauses 5.1.4.2 and 5.1.4.3 only applies to the UEs operating in single-registration mode.<br />
<br />
Regarding the coordination of "SIM/USIM considered invalid" and "USIM considered invalid for 5GS services" between the various mobility management entities see subclause 5.1.5.<br />
<br />
==== 5.1.4.2 Coordination between 5GMM for 3GPP access and EMM with N26 interface ====<br />
<br />
;N26 interface:N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core.<br />
<br />
A UE that is not registered shall be in state EMM-DEREGISTERED and state 5GMM-DEREGISTERED for 3GPP access.<br />
<br />
In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter (see 3GPP TS 24.301).<br />
<br />
At inter-system change from S1 mode to N1 mode, the UE shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP accessand EMM-REGISTERED.NO-CELL-AVAILABLE and initiate a registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).<br />
<br />
In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter or tracking area updating attempt counter (see 3GPP TS 24.301).<br />
<br />
At inter-system change from N1 mode to S1 mode when there is no active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, and EMM-REGISTERED without PDN connection is not supported by the UE or the MME, the UE shall enter state 5GMM-DEREGISTERED for 3GPP access and state EMM-DEREGISTERED and then initiate the EPS attach procedure. If EMM-REGISTERED without PDN connection is supported by the UE and the MME, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure.<br />
<br />
At inter-system change from N1 mode to S1 mode when there is at least one active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure (see 3GPP TS 24.301).<br />
<br />
==== 5.1.4.3 Coordination between 5GMM for 3GPP access and EMM without N26 interface ====<br />
<br />
A UE operating in the single-registration mode that is not registered over 3GPP access shall be in state EMM-DEREGISTERED and in state 5GMM-DEREGISTERED for 3GPP access.<br />
<br />
In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE.<br />
<br />
At inter-system change from N1 mode to S1 mode in 5GMM-IDLE mode, the UE shall behave as specified in subclause 4.8.2.3.<br />
<br />
In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE.<br />
<br />
At inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, the UE operating in the single-registration mode shall enter substates EMM-REGISTERED.NO-CELL-AVAILABLE and 5GMM- REGISTERED.NORMAL-SERVICE for 3GPP access and then initiate the registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).<br />
<br />
=== 5.1.5 Coordination between 5GMM and GMM ===<br />
<br />
Coordination between 5GMM and GMM states is not required.<br />
<br />
Regardless whether the UE is operating in single-registration mode or dual-registration mode,<br />
* if the UE considers the SIM/USIM invalid for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the SIM/USIM invalid for all of them; and<br />
* if the UE considers the USIM invalid for 5GS services for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the USIM invalid for 5GS services for all of them.<br />
<br />
== 5.3 General on elementary 5G Mobility Management (5GMM) procedures ==<br />
<br />
=== 5.3.1 5GMM modes and N1 NAS signalling connection ===<br />
<br />
==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====<br />
When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial Non-Access Stratum (NAS) message, the User Equipment (UE) shall request the lower layer to establish an Radio Resource Controller (RRC) connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access.<br />
<br />
When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access.<br />
<br />
Initial NAS messages are:<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST message;</li><br />
<li>DEREGISTRATION REQUEST message;</li><br />
<li>SERVICE REQUEST message; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST.</li><br />
</ol><br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.<br />
<br />
For the routing of the initial NAS message to the appropriate AMF, if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules...see spec<br />
<br />
== 5.2 Behaviour of the UE in state 5GMM-DEREGISTERED and state 5GMM-REGISTERED ==<br />
<br />
== 5.3 General on elementary 5GMM procedures ==<br />
<br />
=== 5.3.1 5GMM modes and N1 NAS signalling connection ===<br />
<br />
==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====<br />
<br />
<span style="color:red">When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial NAS message, the UE shall request the lower layer to establish an RRC connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access</span>.<br />
<br />
<span style="color:red">When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access</span>.<br />
<br />
Initial NAS messages are:<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST message;</li><br />
<li>DEREGISTRATION REQUEST message;</li><br />
<li>SERVICE REQUEST message; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST.</li><br />
</ol><br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.<br />
<br />
For the routing of the initial NAS message to the appropriate AMF, <span style="color:red">if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules</span>:<br />
<ol type="a"><br />
<li>if the registration procedure for mobility and periodic update was triggered due to the last CONFIGURATION UPDATE COMMAND message containing the Configuration update indication IE with the Registration bit set to "registration requested" and including:<br />
# no other parameters;<br />
# one or both of the Allowed NSSAI IE and the Configured NSSAI IE; or<br />
# the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed";<br />
:the <span style="color:red">UE NAS shall not provide the lower layers with the 5G-S-TMSI or the registered GUAMI</span>;</li><br />
<li>if the service request procedure was initiated over non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the registered GUAMI, but shall not provide the lower layers with the 5G-S-TMSI</span>;</li><br />
<li>if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over untrusted non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI</span>;<br />
<br />
if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over trusted non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the 5G-GUTI, if available, otherwise shall provide the lower layers with the SUCI</span>;<br />
<br />
if the UE is the 5G-RG and the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over wireline access, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, if available, otherwise shall not provide the lower layers with any UE identity</span>;</li><br />
<li>if the UE does not hold a 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration procedure and if:<br />
# the UE operating in the single-registration mode performs a registration procedure for mobility and periodic update indicating "mobility registration updating" following an inter-system change from S1 mode to N1 mode; or<br />
# the UE which was previously registered in S1 mode before entering state EMM-DEREGISTERED, performs an initial registration procedure, the UE has received the interworking without N26 interface indicator set to "interworking without N26 interface not supported" from the network, and the UE holds a 4G-GUTI;<br />
<br />
then <span style="color:red">the UE NAS provides the lower layers with a GUAMI part of the 5G-GUTI mapped from 4G-GUTI as specified in 3GPP TS 23.003 with an indication that the GUAMI is mapped from EPS</span>; or</li><br />
<li>otherwise:<br />
# if the tracking area of the current cell is in the registration area, <span style="color:red">the UE NAS shall provide the lower layers with the 5G-S-TMSI, but shall not provide the registered GUAMI to the lower layers</span>; or<br />
# if the tracking area of the current cell is not in the registration area, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclauses 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI</span>.</li><br />
</ol><br />
<br />
<br />
For 3GPP access and untrusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, <span style="color:red">the UE NAS does not provide the lower layers with the 5G-S-TMSI or the registered GUAMI</span>. For trusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, <span style="color:red">the UE NAS provides the lower layers with the SUCI</span>.<br />
<br />
The UE NAS also provides the lower layers with the identity of the selected PLMN (see 3GPP TS 38.331) if the UE is not operating in SNPN access operation mode. If the UE is operating in SNPN access operation mode, the UE NAS provides the lower layers with the SNPN identity of the selected SNPN. In a shared network, the UE shall choose one of the PLMN identity(ies) or SNPN identity(ies) as specified in 3GPP TS 23.122.<br />
<br />
The UE NAS layer may provide the lower layers with an NSSAI as specified in subclause 4.6.2.3.<br />
<br />
If the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the UE NAS layer shall provide the lower layers with an indication that the connection is for onboarding.<br />
<br />
==== 5.3.1.2 Re-establishment of the N1 NAS signalling connection ====<br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li><span style="color:red">initiate the registration procedure for mobility and periodic registration update</span> and include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.5.1.3 for further details).</li><br />
</ol><br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has pending uplink user data for PDU session(s) with user-plane resources already established but no pending NAS procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication (see subclause 5.6.1 for further details).</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending registration procedure, a service request procedure, or a de-registration procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode;</li><br />
<li>proceed with the pending procedure; and</li><br />
<li>if the pending procedure is a service request or <span style="color:red">registration procedure</span> and the SERVICE REQUEST message, the CONTROL PLANE SERVICE REQUEST message or the REGISTRATION REQUEST message does not include UE request type IE with Request type value set to "NAS signalling connection release", the UE shall include the Uplink data status IE in the SERVICE REQUEST message, or <span style="color:red">in the REGISTRATION REQUEST message</span>, indicating the PDU session(s) for which user-plane resources were not active prior to receiving a fallback indication from the lower layers and the UE has pending user data to be sent over 3GPP access, if any, and the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclauses 5.5.1.3 and 5.6.1 for further details).</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending NAS procedure other than a registration procedure, a service request procedure, or a de-registration procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode;</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details); and</li><br />
<li>upon successful service request procedure completion, proceed with any pending procedure.</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, and the UE was using network resources for ProSe direct discovery over PC5 or ProSe direct communication over PC5 (see 3GPP TS 23.304), the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details).</li><br />
</ol><br />
The cases above apply when the UE is in an allowed area or when the UE is not in a non-allowed area.<br />
<br />
When the UE:<br />
<ol type="a"><br />
<li>is in a non-allowed area or is not in an allowed area;</li><br />
<li>is in 5GMM-CONNECTED mode over 3GPP access;</li><br />
<li>receives a fallback indication from lower layers; and</li><br />
<li>does not have signalling pending,</li><br />
</ol><br />
the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li><span style="color:red">initiate the registration procedure for mobility and periodic registration update</span>. The UE shall not include the Uplink data status IE in the REGISTRATION REQUEST message except if the PDU session for which user-plane resources were active is an emergency PDU session, or if the UE is configured for high priority access in the selected PLMN.</li><br />
</ol><br />
<br />
In the above cases when the UE receives a fallback indication from lower layers, if the UE is in non-allowed area or not in allowed area, the UE shall behave as specified in subclause 5.3.5.<br />
<br />
==== 5.3.1.3 Release of the N1 NAS signalling connection ====<br />
<br />
See spec for details...<br />
<br />
==== 5.3.1.4 5GMM-CONNECTED mode with RRC inactive indication ====<br />
<br />
See spec for details...<br />
<br />
==== 5.3.1.5 Suspend and resume of the N1 NAS signalling connection ====<br />
<br />
See spec for details...<br />
<br />
=== 5.3.2 Permanent identifiers ===<br />
A globally unique permanent identity, the 5G subscription permanent identifier (SUPI), is allocated to each subscriber for 5GS-based services. The IMSI, the network specific identifier, the GCI and the GLI are valid SUPI types. When the SUPI contains a network specific identifier, a GCI or a GLI, it shall take the form of a network access identifier (NAI). When the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the SUPI contains the onboarding SUPI derived from the default UE credentials for primary authentication. The UE derives the onboarding SUPI before or during the initial registration for onboarding services in SNPN and uses the derived onboarding SUPI in the initial registration for onboarding services in SNPN and while registered for onboarding services in SNPN.<br />
<br />
The structure of the SUPI and its derivatives are specified in 3GPP TS 23.003. See [[My 3GPP TS 23.003 notes]]<br />
<br />
The UE provides the SUPI to the network in concealed form. The SUCI is a privacy preserving identifier containing the concealed SUPI. When the SUPI contains a network specific identifier, a GCI or a GLI, the SUCI shall take the form of a NAI as specified in 3GPP TS 23.003.<br />
<br />
<span style="color:red">A UE supporting N1 mode includes a SUCI:</span><br />
<ol type="a"><br />
<li>in the REGISTRATION REQUEST message when the UE is attempting initial registration procedure <span style="color:red">and a valid 5G-GUTI is not available</span>;</li><br />
<li>in the IDENTITY RESPONSE message, <span style="color:red">if the SUCI is requested by the network during the identification procedure</span>; and</li><br />
<li>in the DEREGISTRATION REQUEST message when the UE initiates a de-registration procedure <span style="color:red">and a valid 5G-GUTI is not available</span>.</li><br />
</ol><br />
<span style="color:red">If the UE uses the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI, the SUCI contains the unconcealed SUPI.</span><br />
<br />
When:<br />
* not operating in SNPN access operation mode; or<br />
* operating in SNPN access operation mode but not performing initial registration for onboarding services and not registered for onboarding services;<br />
<br />
the UE shall use the "null-scheme" if:<br />
<ol type="a"><br />
<li>the home network has not provisioned the public key needed to generate a SUCI;</li><br />
<li>the home network has configured "null-scheme" to be used for the UE;</li><br />
<li>the UE needs to perform a registration procedure for emergency services after the failure of authentication procedure or after reception of a REGISTRATION REJECT message with the 5GMM cause #3 "Illegal UE", or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully, and the UE does not have a valid 5G-GUTI for the selected PLMN; or</li><br />
<li>the UE receives an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully.</li><br />
</ol><br />
<br />
When operating in SNPN access operation mode and:<br />
* performing initial registration for onboarding services; or<br />
* registered for onboarding services;<br />
<br />
the UE shall use the "null-scheme" if:<br />
<ol type="a"><br />
<li>the public key needed to generate a SUCI is not configured as part of the default UE credentials for primary authentication; or</li><br />
<li>"null-scheme" usage is configured as part of the default UE credentials.</li><br />
</ol><br />
<br />
If:<br />
<ol type="a"><br />
<li>the UE uses the "null-scheme" as specified in 3GPP TS 33.501 [24] to generate a SUCI;</li><br />
<li>the UE operates in SNPN access operation mode and:<br />
# an indication to use anonymous SUCI which is associated with the selected entry of the "list of subscriber data", is configured in the ME, if the UE is not registering or registered for onboarding services in SNPN; or<br />
# an indication to use anonymous SUCI which is associated with the default UE credentials, is configured in the ME, if the UE is registering or registered for onboarding services in SNPN;</li><br />
NOTE 1: The ME can be configured with an indication to use anonymous SUCI associated with an entry of "list of subscriber data" when the EAP method associated with the credentials of the entry supports SUPI privacy at the EAP layer, or can be configured with an indication to use anonymous SUCI associated with the default UE credentials when the EAP method associated with the default UE credentials supports SUPI privacy at the EAP layer, or both.<br />
</br></br><br />
Editor's note: (WI eNPN, CR 4139) it is FFS whether another UE-level configuration for usage of anonymous SUCI is needed.<br />
<br />
<li>the UE does not need to perform a registration procedure for emergency services, or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully; and</li><br />
<li>the UE does not receive an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully;</li><br />
</ol><br />
then the UE shall use anonymous SUCI as specified in 3GPP TS 23.003.<br />
<br />
A W-AGF acting on behalf of an FN-RG shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.<br />
<br />
A W-AGF acting on behalf of an N5GC device shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.<br />
<br />
If a UE is a MUSIM UE, the UE shall use a separate permanent equipment identifier (PEI) for each USIM, if any, and each entry of "list of subscriber data", if any, the UE operates for accessing 5GS-based services; otherwise, a UE contains and uses a permanent equipment identifier (PEI) for accessing 5GS-based services. When the UE is registered with a network by using a PEI, the UE shall not use that PEI to register with another network until the UE is de-registered from the network.<br />
<br />
In this release of the specification, the IMEI, the IMEISV, the MAC address together with the MAC address usage restriction indication and the EUI-64 are the only PEI formats supported by 5GS. The structure of the PEI and its formats are specified in 3GPP TS 23.003.<br />
<br />
Each UE supporting at least one 3GPP access technology (i.e. satellite NG-RAN, NG-RAN, E-UTRAN, UTRAN or GERAN) contains a PEI in the IMEI format and shall be able to provide an IMEI and an IMEISV upon request from the network.<br />
<br />
Each UE not supporting any 3GPP access technologies and supporting NAS over untrusted or trusted non-3GPP access shall have a PEI in the form of the Extended Unique Identifier EUI-64 of the access technology the UE uses to connect to the 5GC.<br />
<br />
A UE supporting N1 mode includes a PEI:<br />
<ol type="a"><br />
<li>when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";</li><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTITY RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
<br />
Each 5G-RG supporting only wireline access and each FN-RG shall have a permanent MAC address configured by the manufacturer. For 5G-CRG, the permanent MAC address configured by the manufacturer shall be a cable modem MAC address.<br />
<br />
When the 5G-RG contains neither an IMEI nor an IMEISV, the 5G-RG shall use as a PEI the 5G-RG's permanent MAC address configured by the manufacturer and the MAC address usage restriction indication set to "no restrictions".<br />
<br />
The Wireless Access Gateway Function (W-AGF) acting on behalf of the Fixed Network Residential Gateway (FN-RG) shall use as a PEI the MAC address provided by the FN-RG and if the MAC address provided by the FN-RG is not unique or does not correspond to the FN-RG's permanent MAC address according to W-AGF's configuration, the MAC address usage restriction indication set to "MAC address is not usable as an equipment identifier" otherwise the MAC address usage restriction indication set to "no restrictions".<br />
<br />
The 5G-RG containing neither an IMEI nor an IMEISV shall include the PEI containing the MAC address together with the MAC address usage restriction indication:<br />
<ol type="a"><br />
<li>when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";</li><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
:NOTE 2: In case c) above, the MAC address is provided even though AMF requests the IMEISV.<br />
<br />
The W-AGF acting on behalf of the FN-RG shall include the PEI containing the MAC address together with the MAC address usage restriction indication:<br />
<ol type="a"><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
:NOTE 3: In case b) above, the MAC address is provided even though AMF requests the IMEISV.<br />
<br />
The W-AGF acting on behalf of the N5GC device shall use as a PEI the MAC address provided by the N5GC device and the MAC address usage restriction indication set to "no restrictions". Based on operator policy, the W-AGF acting on behalf of the N5GC device may encode the MAC address of the N5GC device using the EUI-64 format as specified in IEEE "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" and use as a PEI the derived EUI-64.<br />
:NOTE 4: The MAC address of an N5GC device is universally/globally unique.<br />
<br />
The AMF can request the PEI at any time by using the identification procedure.<br />
<br />
=== 5.3.3 Temporary identities ===<br />
<br />
<span style="color:red">A temporary user identity for 5GS-based services, the 5G globally unique temporary identity (5G-GUTI), is used for identification within the signalling procedures. In case of PLMN the 5G-GUTI is globally unique and in case of Standalone Non-Public Network (SNPN) the 5G-GUTI is unique within an SNPN. When the UE is registered to the same PLMN or SNPN over 3GPP and non-3GPP access, the UE and the AMF maintain one 5G-GUTI that is common to both 3GPP and non-3GPP access. When the UE is required to delete the 5G-GUTI according to a NAS procedure, the UE shall delete the 5G-GUTI only if it is not registered to the same PLMN or SNPN through other access. When the UE is registered to different PLMNs or SNPNs over 3GPP access and non-3GPP access, the UE maintains two 5G-GUTIs, a 5G-GUTI for the registration with a PLMN or SNPN over the 3GPP access and another 5G-GUTI for the registration with another PLMN or SNPN over the non-3GPP access. In the paging and service request procedures, a shortened form of the 5G-GUTI, the 5G S-temporary mobile subscriber identity (5G-S-TMSI), is used to enable more efficient radio signalling. The purpose of the 5G-GUTI and 5G-S-TMSI is to provide identity confidentiality, i.e., to protect a user from being identified and located by an intruder.</span> The structure of the 5G-GUTI and its derivatives are specified in 3GPP TS 23.003. The 5G-GUTI has two main components (see 3GPP TS 23.501):<br />
<ol type="a"><li>the GUAMI; and</li><br />
<li>the 5G-TMSI that provides an unambiguous identity of the UE within the AMF(s) identified by the GUAMI.</li><br />
</ol><br />
:NOTE: The UE registered with an SNPN over non-3GPP access refers to the UE accessing SNPN services via a PLMN.<br />
<br />
The 5G-S-TMSI has three main components:<br />
<ol type="a"><br />
<li>the AMF set ID that uniquely identifies the AMF set within the AMF region;</li><br />
<li>the AMF pointer that identifies one or more AMFs within the AMF set; and</li><br />
<li>the 5G-TMSI.</li><br />
</ol><br />
<br />
A UE supporting N1 mode includes a valid 5G-GUTI, if any is available, in the REGISTRATION REQUEST and DEREGISTRATION REQUEST messages. In the SERVICE REQUEST message, the UE includes a valid 5G-S-TMSI as user identity. <span style="color:red">The AMF shall assign a new 5G-GUTI for a particular UE</span>:<br />
<ol type="a"><br />
<li><span style="color:green">during a successful initial registration procedure</span>;</li><br />
<li><span style="color:green">during a successful registration procedure for mobility registration update</span>;</li><br />
<li><span style="color:green">after a successful service request procedure invoked as a response to a paging request from the network and before</span> the:<br />
# release of the N1 NAS signalling connection; or<br />
# suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;<br />
:as specified in subclause 5.4.4.1; and</li><br />
<li><span style="color:green">after the AMF receives an indication from the lower layers that it has received the NGAP UE context resume request message as specified in 3GPP TS 38.413 for a UE in 5GMM-IDLE mode with suspend indication and this resumption is a response to a paging request from the network, and before</span> the:<br />
# release of the N1 NAS signalling connection; or<br />
# suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;<br />
:as specified in subclause 5.4.4.1.</li><br />
</ol><br />
<br />
<span style="color:red">The AMF should assign a new 5G-GUTI for a particular UE during a successful registration procedure for periodic registration update.</span> <span style="color:red">The AMF may assign a new 5G-GUTI at any time for a particular UE by performing the generic UE configuration update procedure.</span><br />
<br />
If a new 5G-GUTI is assigned by the AMF, the UE and the AMF handle the 5G-GUTI as follows:<br />
<ol type="a"><li>Upon receipt of a 5GMM message containing a new 5G-GUTI, the UE considers the new 5G-GUTI as valid and the old 5G-GUTI as invalid, stops timer T3519 if running, and deletes any stored SUCI. The new 5G-GUTI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.</li><br />
<li>The AMF considers the old 5G-GUTI as invalid as soon as an acknowledgement for a registration or generic UE configuration update procedure is received.</li><br />
</ol><br />
<br />
=== 5.3.4 Registration areas ===<br />
<br />
Within the 5GS, <span style="color:red">the registration area is managed independently per access type, i.e., 3GPP access or non-3GPP access. The AMF assigns a registration area to the UE during the registration procedure</span>. A registration area is defined as a set of tracking areas and each of these tracking areas consists of one or more cells that cover a geographical area. Within the 5GS, the concept of "registration to multiple tracking areas" applies:<br />
<ol type="a"><br />
<li>A tracking area is identified by a TAI which is broadcast in the cells of the tracking area. The TAI is constructed from a TAC and a PLMN identity. In case of a shared network:<br />
<ol type="1"><li>one or more TACs; and</li><br />
<li>any of the following:<br />
<ol type="i"><br />
<li>multiple PLMN identities;</li><br />
<li>multiple SNPN identities; or</li><br />
<li>one or more PLMN identities and one or more SNPN identities;<br />
are broadcast.</li></ol><br />
</li></ol><br />
<li>In order to reduce the tracking area update signalling within the 5GS, the AMF can assign several tracking areas to the UE. These tracking areas construct a list of tracking areas which is identified by a TAI list. When generating the TAI list, the AMF shall include only TAIs that are applicable on the access where the TAI list is sent. The AMF shall be able to allocate a TAI list over different NG-RAN access technologies. The AMF shall not allocate a TAI list containing both tracking areas in NB-N1 mode and tracking areas not in NB-N1 mode.</li><br />
<li>The UE considers itself registered to a list of tracking areas and does not need to trigger the registration procedure for mobility and periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) as long as the UE stays in one of the tracking areas of the list of tracking areas received from the AMF.</li><br />
<li>The UE will consider the TAI list as valid, until it receives a new TAI list in the next registration procedure for mobility and periodic registration update or generic UE configuration update procedure, or the UE is commanded by the network to delete the TAI list by a reject message or it is deregistered from the 5GS. If the registration request is accepted or the TAI list is reallocated by the AMF, the AMF shall provide at least one entry in the TAI list. If the new and the old TAI list are identical, the AMF does not need to provide the new TAI list to the UE during mobility registration update or periodic registration update.</li><br />
<li>The TAI list can be reallocated by the AMF.</li><br />
<li>When the UE is deregistered from the 5GS, the TAI list in the UE is invalid.</li><br />
<li>The UE includes the last visited registered TAI, if available, to the AMF. The last visited registered TAI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.</li><br />
</ol><br />
<br />
=== 5.3.5 Service area restrictions ===<br />
<br />
==== 5.3.5.1 General ====<br />
<br />
Service area restrictions are applicable only to 3GPP access and to wireline access.<br />
<br />
Subclause 5.3.5.2 applies when the UE accesses 5GCN over 3GPP access.<br />
<br />
Subclause 5.3.5.3 applies when the 5G-RG or the W-AGF acting on behalf of an FN-CRG (or on behalf of the N5GC device) access 5GCN over wireline access.<br />
:NOTE: Service area restrictions are not applicable for the W-AGF acting on behalf of the FN-BRG.<br />
<br />
==== 5.3.5.2 3GPP access service area restrictions ====<br />
<br />
<span style="color:blue">The service area restrictions consist of tracking areas forming either an allowed area, or a non-allowed area</span>. The tracking areas belong to either the registered PLMN or its equivalent PLMNs in the registration area. The allowed area can contain up to 16 tracking areas or include all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area. The non-allowed area can contain up to 16 tracking areas. The network conveys the service area restrictions to the UE by including either an allowed area, or a non-allowed area, but <span style="color:red">not both</span>, in the Service area list IE of a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message.<br />
<br />
If the network does not convey the service area restrictions to the UE in the Service area list IE of a REGISTRATION ACCEPT message, the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".<br />
<br />
When the UE receives a Service area list IE with an allowed area indication during a registration procedure or a generic UE configuration update procedure:<br />
<ol type="a"><br />
<li>if the "Type of list" included in the Service area list IE does not indicate "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall delete the old list of "allowed tracking areas" and store the tracking areas in the allowed area as the list of "allowed tracking areas". If the UE has a stored list of "non-allowed tracking areas", the UE shall delete that list; or</li><br />
<li>if the "Type of list" included in the Service area list IE indicates "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".</li><br />
</ol><br />
<br />
When the UE receives a Service area list IE with a non-allowed area indication during a registration procedure or a generic UE configuration update procedure, the UE shall delete the old list of "non-allowed tracking areas" and store the tracking areas in the non-allowed area as the list of "non-allowed tracking areas". If the UE has a stored list of "allowed tracking areas", the UE shall delete that list.<br />
<br />
If the UE is successfully registered to a PLMN and has a stored list of "allowed tracking areas":<br />
<br />
See spec for details...<br />
<br />
=== 5.3.6 Mobile initiated connection only (MICO) mode ===<br />
<br />
=== 5.3.7 Handling of the periodic registration update timer and mobile reachable timer ===<br />
<br />
The periodic registration update procedure is used over 3GPP access to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic registration update timer, T3512.<br />
<br />
If the UE is registered over the 3GPP access, the AMF maintains an implicit de-registration timer to control when the UE is considered implicitly de-registered over the 3GPP access. If the UE is registered over the non-3GPP access, the AMF also maintains a non-3GPP implicit de-registration timer to control when the UE is considered implicitly de-registered over the non-3GPP access. The UE registered over the non-3GPP access maintains a non-3GPP de-registration timer to control when the UE is considered implicitly de-registered for the non-3GPP access.<br />
<br />
The AMF shall start a non-3GPP implicit de-registration timer for the UE registered over non-3GPP access when the N1 NAS signalling connection over non-3GPP access is released.<br />
<br />
The UE registered over non-3GPP access shall reset and start a non-3GPP de-registration timer when the N1 NAS signalling connection over non-3GPP access is released. The non-3GPP de-registration timer is stopped when the UE enters 5GMM-CONNECTED mode over non-3GPP access or the 5GMM-DEREGISTERED state over non-3GPP access.<br />
<br />
The non-3GPP implicit de-registration timer shall be longer than the non-3GPP de-registration timer.<br />
<br />
The value of timer T3512 is sent by the network to the UE in the REGISTRATION ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE until a new value is received. The periodic registration update timer only applies to the UE registered to the 5GS services over 3GPP access.<br />
<br />
If timer T3512 received by the UE in a REGISTRATION ACCEPT message contains an indication that the timer is deactivated or the timer value is zero, then timer T3512 is deactivated and the UE shall not perform the periodic registration update procedure.<br />
:NOTE 1: The UE does not perform the periodic registration update procedure for non-3GPP access.<br />
<br />
If during the registration procedure, the AMF does not indicate "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is reset and started with its initial value, when the UE changes from 5GMM-CONNECTED over 3GPP access to 5GMM-IDLE mode over 3GPP access. Timer T3512 is stopped when the UE enters 5GMM-CONNECTED mode over 3GPP access or the 5GMM-DEREGISTERED state over 3GPP access.<br />
<br />
If during the registration procedure, the AMF indicates "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is started with its initial value after the completion of the registration procedure. The UE shall neither stop nor reset the timer T3512 when the UE enters 5GMM-CONNECTED or when changing from 5GMM-CONNECTED mode to 5GMM-IDLE mode. If the timer T3512 expires,<br />
<ol type="a"><br />
<li>the UE in 5GMM-CONNECTED mode over 3GPP access shall reset and start the timer T3512 with its initial value; or</li><br />
<li>the UE in 5GMM-IDLE mode over 3GPP access shall perform the periodic registration procedure.</li><br />
</ol><br />
<br />
If the UE is registered for emergency services, and timer T3512 expires, the UE shall not initiate a periodic registration update procedure, but shall locally de-register from the network. When the UE is camping on a suitable cell, it may re-register to regain normal service.<br />
<br />
When a UE is not registered for emergency services, and timer T3512 expires when the UE is in 5GMM-IDLE mode, the periodic registration update procedure shall be started.<br />
<br />
If the UE is not registered for emergency services, and is in a state other than 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access when timer T3512 expires, the periodic registration update procedure is delayed until the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access.<br />
:NOTE 2: When the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE and it needs to initiate other 5GMM procedure than the periodic registration update procedure then, based on UE implementation, the 5GMM procedure can take precedence.<br />
<br />
The network supervises the periodic registration update procedure of the UE by means of the mobile reachable timer.<br />
<br />
If the UE is not registered for emergency services, the mobile reachable timer shall be longer than the value of timer T3512. In this case, by default, the mobile reachable timer is 4 minutes greater than the value of timer T3512.<br />
<br />
The network behaviour upon expiry of the mobile reachable timer is network dependent, but typically the network stops sending paging messages to the UE on the first expiry, and may take other appropriate actions.<br />
<br />
If the UE is registered for emergency services, the AMF shall set the mobile reachable timer with a value equal to timer T3512. When the mobile reachable timer expires, the AMF shall locally de-register the UE.<br />
<br />
The mobile reachable timer shall be reset and started with the value as indicated above, when the AMF releases the NAS signalling connection for the UE. The mobile reachable timer shall be stopped when a NAS signalling connection is established for the UE.<br />
<br />
Upon expiry of the mobile reachable timer the network shall start the implicit de-registration timer over 3GPP access. The value of the implicit de-registration timer over 3GPP access is network dependent. If MICO mode is activated, the network shall start the implicit de-registration timer over 3GPP access when the UE enters 5GMM-IDLE mode at the AMF over 3GPP access. The default value of the implicit de-registration timer over 3GPP access is 4 minutes greater than the value of timer T3512.<br />
<br />
If the implicit de-registration timer expires before the UE contacts the network, the network shall implicitly de-register the UE. The implicit de-registration timer shall be stopped when a NAS signalling connection is established for the UE.<br />
<br />
If the non-3GPP implicit de-registration timer expires before the UE contacts the network over the non-3GPP access, the network shall implicitly de-register the UE and enter the state 5GMM-DEREGISTERED over non-3GPP access for the UE. The non-3GPP implicit de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.<br />
<br />
If the non-3GPP de-registration timer expires before the UE contacts the network over the non-3GPP access, the UE shall enter the state 5GMM-DEREGISTERED over non-3GPP access. The non-3GPP de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.<br />
<br />
If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "Non-3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of timer T3512, the AMF sets the mobile reachable timer and the implicit de-registration timer such that the sum of the timer values is greater than the value of timer T3346.<br />
<br />
If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the AMF sets the non-3GPP implicit de-registration timer value to be 8 minutes greater than the value of timer T3346.<br />
<br />
If the UE receives T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the UE sets the non-3GPP de-registration timer value to be 4 minutes greater than the value of timer T3346.<br />
<br />
=== 5.3.9 Handling of NAS level mobility management congestion control ===<br />
<br />
== 5.4 5GMM common procedures ==<br />
<br />
=== 5.4.2 Security mode control (SMC) procedure ===<br />
<br />
==== 5.4.2.1 General ====<br />
<br />
The purpose of the NAS security mode control procedure is to take a 5G NAS security context into use, and initialise and start NAS signalling security between the UE and the AMF with the corresponding 5G NAS keys and 5G NAS security algorithms.<br />
<br />
See spec for details...<br />
<br />
=== 5.4.3 Identification procedure ===<br />
<br />
==== 5.4.3.1 General ====<br />
<br />
The purpose of this procedure is to request a particular UE to provide specific identification parameters, e.g. the SUCI, the IMEI, the IMEISV, the EUI-64 or the MAC address. The SUCI is a privacy preserving identifier containing the concealed SUPI and the IMEI, the IMEISV, the EUI-64 and the MAC address are formats of PEI.<br />
<br />
See spec for details...<br />
<br />
== 5.5 5GMM specific procedures ==<br />
<br />
=== 5.5.1 Registration procedure ===<br />
<br />
==== 5.5.1.1 General ====<br />
<br />
The registration procedure is always initiated by the UE and used for initial registration as specified in subclause 5.5.1.2.2 or mobility and periodic registration update as specified in subclause 5.5.1.3.2.<br />
<br />
When the UE needs to initiate registration over both 3GPP access and non-3GPP access in the same PLMN (e.g. the 3GPP access and the selected N3IWF are located in the same PLMN), the UE:<br />
<ol type="a"><br />
<li>in 5GMM-REGISTERED-INITIATED over 3GPP access shall not initiate registration over non-3GPP access; or</li><br />
<li>in 5GMM-REGISTERED-INITIATED over non-3GPP access shall not initiate registration over 3GPP access.</li><br />
:NOTE 1: To which access (i.e. 3GPP access or non-3GPP access) the UE initiates registration first is up to UE implementation.<br />
</ol><br />
<br />
When the UE is registered with a PLMN over a non-3GPP access, the AMF and the UE maintain:<br />
<ol type="a"><br />
<li>registration state and state machine over non-3GPP access;</li><br />
<li>5G NAS security context;</li><br />
<li>5G-GUTI;</li><br />
<li>registration area for non-3GPP access, which is associated with a single TAI; and</li><br />
<li>non-3GPP de-registration timer in the UE and non-3GPP implicit de-registration timer in the AMF.</li><br />
</ol><br />
<br />
A registration attempt counter is used to limit the number of subsequently rejected registration attempts. The registration attempt counter shall be incremented as specified in subclause 5.5.1.2.7 or subclause 5.5.1.3.7. Depending on the value of the registration attempt counter, specific actions shall be performed. The registration attempt counter shall be reset when:<br />
* the UE is powered on;<br />
* a USIM is inserted;<br />
* a registration procedure is successfully completed;<br />
* an EPS attach or combined EPS attach procedure is successfully completed in S1 mode and the UE is operating in single-registration mode. In this case, the UE shall reset the registration attempt counter for 3GPP access;<br />
:NOTE 2: The registration attempt counter for non-3GPP access is not impacted by the EPS attach and the combined EPS attach procedure.<br />
* a registration procedure is rejected with cause #11, #12, #13, #15, #27, #31, #62, #72, #73, #74, #75, #76, #77 or #78;<br />
* a registration procedure is rejected with cause #3, #6 or #7, the REGISTRATION REJECT message is received without integrity protection and the counter for "SIM/USIM considered invalid for GPRS services" events has a value less than a UE implementation-specific maximum value.<br />
* a network initiated deregistration procedure is completed with cause #11, #12, #13, #15, #27; #62, #72, #74, #75, #76, #77 or #78; or<br />
* a new PLMN or SNPN is selected.<br />
<br />
Additionally, the registration attempt counter shall be reset when the UE is in substate 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION or 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE, and:<br />
* the current TAI is changed;<br />
* timer T3502 expires; or<br />
* timer T3346 is started.<br />
When the registration attempt counter is reset, the UE shall stop timer T3519 if running, and delete any stored SUCI.<br />
<br />
The lower layers indicate to NAS whether the network supports emergency services for the UE in limited service state (see 3GPP TS 38.331). This information is taken into account when deciding whether to initiate an initial registration for emergency services.<br />
<br />
==== 5.5.1.2 Registration procedure for initial registration ====<br />
<br />
===== 5.5.1.2.1 General =====<br />
<br />
This procedure can be used by a UE for initial registration for 5GS services.<br />
<br />
When the UE initiates the registration procedure for initial registration, the UE shall indicate "initial registration" in the 5GS registration type IE. When the UE initiates the registration procedure for emergency services, the UE shall indicate "emergency registration" in the 5GS registration type IE. When the UE initiates the initial registration for onboarding services in SNPN, the UE shall indicate "SNPN onboarding registration" in the 5GS registration type IE. When the UE initiates the initial registration procedure for disaster roaming services, the UE shall indicate "disaster roaming initial registration" in the 5GS registration type IE.<br />
<br />
If the MUSIM UE initiates the registration procedure for initial registration and indicates "emergency registration" in the 5GS registration type IE in the REGISTRATION REQUEST message, the network shall not indicate the support of:<br />
* the N1 NAS signalling connection release;<br />
* the paging indication for voice services;<br />
* the reject paging request; or<br />
* the paging restriction;<br />
in the REGISTRATION ACCEPT message.<br />
<br />
===== 5.5.1.2.2 Initial registration initiation =====<br />
The UE in state 5GMM-DEREGISTERED shall initiate the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF,<br />
<ol type="a"><br />
<li>when the UE performs initial registration for 5GS services;</li><br />
<li>when the UE performs initial registration for emergency services;</li><br />
<li>when the UE performs initial registration for SMS over NAS;</li><br />
<li>when the UE moves from GERAN to NG-RAN coverage or the UE moves from a UTRAN to NG-RAN coverage and the following applies:<br />
# the UE initiated a GPRS attach or routing area updating procedure while in A/Gb mode or Iu mode; or<br />
# the UE has performed 5G-SRVCC from NG-RAN to UTRAN as specified in 3GPP TS 23.216,<br />
:and since then the UE did not perform a successful EPS attach or tracking area updating procedure in S1 mode or registration procedure in N1 mode;<br />
<li>when the UE performs initial registration for onboarding services in SNPN; and</li><br />
<li>when the UE performs initial registration for disaster roaming services;</li><br />
</ol><br />
with the following clarifications to initial registration for emergency services:<br />
<ol type="a"><br />
<li>the UE shall not initiate an initial registration for emergency services over the current access, if the UE is already registered for emergency services over the non-current access, unless the initial registration has to be initiated to perform handover of an existing emergency PDU session from the non-current access to the current access; and</li><br />
NOTE 1: Transfer of an existing emergency PDU session between 3GPP access and non-3GPP access is needed e.g. if the UE determines that the current access is no longer available.<br />
<li>the UE can only initiate an initial registration for emergency services over non-3GPP access if it cannot register for emergency services over 3GPP access.</li><br />
</ol><br />
<br />
The UE initiates the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF, starting timer T3510. If timer T3502 is currently running, the UE shall stop timer T3502. If timer T3511 is currently running, the UE shall stop timer T3511.<br />
<br />
<span style="color:red">During initial registration the UE handles the 5GS mobile identity IE in the following order:</span><br />
<ol type="a"><br />
<li>if:<br />
<ol type="1"><br />
<li>the UE:</li><br />
<ol type="i"><br />
<li>was previously registered in S1 mode before entering state EMM-DEREGISTERED; and</li><br />
<li>has received an "interworking without N26 interface not supported" indication from the network; and</li><br />
</ol><br />
<li>EPS security context and a valid native 4G-GUTI are available;</li><br />
</ol><br />
<br />
then the UE shall create a 5G-GUTI mapped from the valid native 4G-GUTI as specified in 3GPP TS 23.003 and indicate the mapped 5G-GUTI in the 5GS mobile identity IE. The UE shall include the UE status IE with the EMM registration status set to "UE is not in EMM-REGISTERED state" and shall include an ATTACH REQUEST message as specified in 3GPP TS 24.301 in the EPS NAS message container IE.<br />
<br />
Additionally, if the UE holds a valid 5G GUTI, the UE shall include the 5G-GUTI in the Additional GUTI IE in the REGISTRATION REQUEST message in the following order:<br />
# a valid 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration, if available;<br />
# a valid 5G-GUTI that was previously assigned by an equivalent PLMN, if available; and<br />
# a valid 5G-GUTI that was previously assigned by any other PLMN, if available;<br />
<br />
<li>if:<br />
# the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same PLMN with which the UE is performing the registration, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or<br />
# the UE is registering with a SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same SNPN with which the UE is performing the registration, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;</li><br />
<br />
<li>if the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by an equivalent PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;</li><br />
<br />
<li>if:<br />
# the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or<br />
# the UE is registering with an SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other SNPN, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE and shall additionally include the NID of the other SNPN in the NID IE;</li><br />
<br />
<li>if a SUCI other than an onboarding SUCI is available, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall include the SUCI other than an onboarding SUCI in the 5GS mobile identity IE;</li><br />
<li>if the UE does not hold a valid 5G-GUTI or SUCI other than an onboarding SUCI, and is initiating the initial registration for emergency services, the PEI shall be included in the 5GS mobile identity IE; and</li><br />
<li>if the UE is initiating the initial registration for onboarding services in SNPN, an onboarding SUCI shall be included in the 5GS mobile identity IE.</li><br />
</ol><br />
:NOTE 2: The AMF in ON-SNPN uses the onboarding SUCI as specified in 3GPP TS 23.501.<br />
<br />
If the SUCI is included in the 5GS mobile identity IE and the timer T3519 is not running, the UE shall start timer T3519 and store the value of the SUCI sent in the REGISTRATION REQUEST message. The UE shall include the stored SUCI in the REGISTRATION REQUEST message while timer T3519 is running.<br />
<br />
If the UE is operating in the dual-registration mode and it is in EMM state EMM-REGISTERED, the UE shall include the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state".<br />
<br />
:NOTE 3: Inclusion of the UE status IE with this setting corresponds to the indication that the UE is "moving from EPC" as specified in 3GPP TS 23.502.<br />
:NOTE 4: The value of the 5GMM registration status included by the UE in the UE status IE is not used by the AMF.<br />
<br />
If the last visited registered TAI is available, the UE shall include the last visited registered TAI in the REGISTRATION REQUEST message.<br />
<br />
If the UE requests the use of SMS over NAS, the UE shall include the 5GS update type IE in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS supported". When the 5GS update type IE is included in the REGISTRATION REQUEST for reasons other than requesting the use of SMS over NAS, and the UE does not need to register for SMS over NAS, the UE shall set the SMS requested bit of the 5GS update type IE to "SMS over NAS not supported" in the REGISTRATION REQUEST message.<br />
<br />
See spec for more info...<br />
<br />
...<br />
<br />
If the UE does not have a valid 5G NAS security context, <span style="color:red">the UE shall send the REGISTRATION REQUEST message without including the NAS message container IE.</span> The UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs and non-cleartext IEs, if any) in the NAS message container IE that is sent as part of the SECURITY MODE COMPLETE message as described in subclauses 4.4.6 and 5.4.2.3.<br />
<br />
If the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6. If the UE does not need to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message without including the NAS message container IE.<br />
<br />
<br />
...<br />
<br />
== 8.2 5GS mobility management messages ==<br />
<br />
=== 8.2.6 Registration Request ===<br />
<br />
==== 8.2.6.1 Message definition ====<br />
The REGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.6.1.1.<br />
;Message type:REGISTRATION REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
{| class="wikitable"<br />
|+ Table 8.2.6.1.1: REGISTRATION REQUEST message content<br />
|-<br />
! IEI !! Information Element !! Type/Reference !! Presence !! Format !! Length<br />
|-<br />
| || Extended protocol discriminator || Extended Protocol discriminator 9.2 || M || V || 1<br />
|-<br />
| || Security header type || Security header type 9.3 || M || V || 1/2<br />
|-<br />
| || Spare half octet || Spare half octet 9.5 || M || V || 1/2<br />
|-<br />
| || Registration request message identity || Message type 9.7 || M || V || 1<br />
|-<br />
| || 5GS registration type || 5GS registration type 9.11.3.7 || M || V || 1/2<br />
|-<br />
| || ngKSI || NAS key set identifier 9.11.3.32 || M || V || 1/2<br />
|-<br />
| || <span style="color:red">5GS mobile identity</span> || <span style="color:red">5GS mobile identity 9.11.3.4</span> || M || LV-E || 6-n<br />
|-<br />
| C- || Non-current native NAS key set identifier || NAS key set identifier 9.11.3.32 || O || TV || 1<br />
|-<br />
| 10 || 5GMM capability || 5GMM capability 9.11.3.1 || O || TLV || 3-15<br />
|-<br />
| 2E || UE security capability || UE security capability 9.11.3.54 || O || TLV || 4-10<br />
|-<br />
| 2F || Requested NSSAI || NSSAI 9.11.3.37 || O || TLV || 4-74<br />
|-<br />
| 52 || Last visited registered TAI || 5GS tracking area identity 9.11.3.8 || O || TV || 7<br />
|-<br />
| 17 || S1 UE network capability || S1 UE network capability 9.11.3.48 || O || TLV || 4-15<br />
|-<br />
| 40 || Uplink data status || Uplink data status 9.11.3.57 || O || TLV || 4-34<br />
|-<br />
| 50 || PDU session status || PDU session status 9.11.3.44 || O || TLV || 4-34<br />
|-<br />
| B- || MICO indication || MICO indication 9.11.3.31 || O || TV || 1<br />
|-<br />
| 2B || UE status || UE status 9.11.3.56 || O || TLV || 3<br />
|-<br />
| 77 || Additional GUTI || 5GS mobile identity 9.11.3.4 || O || TLV-E || 14<br />
|-<br />
| 25 || Allowed PDU session status || Allowed PDU session status 9.11.3.13 || O || TLV || 4-34<br />
|-<br />
| 18 || UE's usage setting || UE's usage setting 9.11.3.55 || O || TLV || 3<br />
|-<br />
| 51 || Requested DRX parameters || 5GS DRX parameters 9.11.3.2A || O || TLV || 3<br />
|-<br />
| 70 || EPS NAS message container || EPS NAS message container 9.11.3.24 || O || TLV-E || 4-n<br />
|-<br />
| 74 || LADN indication || LADN indication 9.11.3.29 || O || TLV-E || 3-811<br />
|-<br />
| 8- || Payload container type || Payload container type 9.11.3.40 || O || TV || 1<br />
|-<br />
| 7B || Payload container || Payload container 9.11.3.39 || O || TLV-E || 4-65538<br />
|-<br />
| 9- || Network slicing indication || Network slicing indication 9.11.3.36 || O || TV || 1<br />
|-<br />
| 53 || 5GS update type || 5GS update type 9.11.3.9A || O || TLV || 3<br />
|-<br />
| 41 || Mobile station classmark 2 || Mobile station class mark 2 9.11.3.31C || O || TLV || 5<br />
|-<br />
| 42 || Supported codecs || Supported codec list 9.11.3.51A || O || TLV || 5-n<br />
|-<br />
| 71 || NAS message container || NAS message container 9.11.3.33 || O || TLV-E || 4-n<br />
|-<br />
| 60 || EPS bearer context status || EPS bearer context status 9.11.3.23A || O || TLV || 4<br />
|-<br />
| 6E || Requested extended DRX parameters || Extended DRX parameters 9.11.3.26A || O || TLV || 3<br />
|-<br />
| 6A || T3324 value || GPRS timer 3 9.11.2.5 || O || TLV || 3<br />
|-<br />
| 67 || UE radio capability ID || UE radio capability ID 9.11.3.68 || O || TLV || 3-n<br />
|-<br />
| 35 || Requested mapped NSSAI || Mapped NSSAI 9.11.3.31B || O || TLV || 3-42<br />
|-<br />
| 48 || Additional information requested || Additional information requested 9.11.3.12A || O || TLV || 3<br />
|-<br />
| 1A || Requested WUS assistance information || WUS assistance information 9.11.3.71 || O || TLV || 3-n<br />
|-<br />
| A- || N5GC indication || N5GC indication 9.11.3.72 || O || TV || 1<br />
|-<br />
| 30 || Requested NB-N1 mode DRX parameters || NB-N1 mode DRX parameters 9.11.3.73 || O || TLV || 3<br />
|-<br />
| 29 || UE request type || UE request type 9.11.3.76 || O || TLV || 3<br />
|-<br />
| 28 || Paging restriction || Paging restriction 9.11.3.77 || O || TLV || 3-35<br />
|-<br />
| 72 || Service-level-AA container || Service-level-AA container 9.11.2.10 || O || TLV-E || 6-n<br />
|-<br />
| 32 || NID || NID 9.11.3.79 || O || TLV || 8<br />
|-<br />
| 16 || MS determined PLMN with disaster condition || PLMN identity 9.11.3.85 || O || TLV || 5<br />
|-<br />
| 2A || Requested PEIPS assistance information || PEIPS assistance information 9.11.3.80 || O || TLV || 3-n<br />
|}<br />
<br />
See spec for details of each message.<br />
<br />
==== 8.2.6.21 NAS message container ====<br />
This IE shall be included if the UE is sending a REGISTRATION REQUEST message as an initial NAS message, the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs.<br />
<br />
=== 8.2.12 De-registration request (UE originating de-registration) ===<br />
<br />
==== 8.2.12.1 Message definition ====<br />
The DEREGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.12.1.1.<br />
<br />
;Message type:DEREGISTRATION REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
=== 8.2.16 Service request ===<br />
<br />
==== 8.2.16.1 Message definition ====<br />
The SERVICE REQUEST message is sent by the UE to the AMF in order to request the establishment of an N1 NAS signalling connection and/or to request the establishment of user-plane resources for PDU sessions which are established without user-plane resources. See table 8.2.16.1.1.<br />
<br />
;Message type:SERVICE REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
=== 8.2.30 Control Plane Service request ===<br />
<br />
==== 8.2.30.1 Message definition ====<br />
The CONTROL PLANE SERVICE REQUEST message is sent by the UE to the AMF when the UE is using 5GS services with control plane CIoT 5GS optimization. See table 8.2.30.1.1.<br />
<br />
;Message type:CONTROL PLANE SERVICE REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
== 9.1 General message format and information elements coding Overview ==<br />
See spec for details of section 9.<br />
<br />
=== 9.1.1 NAS message format ===<br />
<br />
Within the protocols defined in the present document, every 5GS NAS message is a standard L3 message as defined in 3GPP TS 24.007.<br />
<br />
== 9.11 Other information elements ==<br />
<br />
=== 9.11.1 General ===<br />
<br />
<span style="color:red">The different formats (V, LV, T, TV, TLV, LV-E, TLV-E) and the five categories of information elements (type 1, 2, 3, 4 and 6) are defined in 3GPP TS 24.007.</span><br />
<br />
The first octet of an information element in the non-imperative part contains the IEI of the information element. If this octet does not correspond to an IEI known in the message, the receiver shall determine whether this IE is of type 1 or 2 (i.e., it is an information element of one octet length) or an IE of type 4 (i.e., that the next octet is the length indicator indicating the length of the remaining of the information element) (see 3GPP TS 24.007).<br />
<br />
This allows the receiver to jump over unknown information elements and to analyze any following information elements of a particular message.<br />
<br />
The definitions of information elements which are:<br />
<ol type="a"><br />
<li>common for the 5GMM and 5GSM protocols;</li><br />
<li>used by access stratum protocols; or</li><br />
<li>sent to upper layers</li><br />
</ol><br />
are described in subclause 9.11.2.<br />
<br />
The information elements of the 5GMM or 5GSM protocols can be defined by reference to an appropriate specification which provides the definition of the information element, e.g., "see subclause 10.5.6.3A in 3GPP TS 24.008".<br />
<br />
See spec for details...<br />
<br />
=== 9.11.3 5GS mobility management (5GMM) information elements ===<br />
<br />
See spec for details...<br />
<br />
==== <span style="color:red">9.11.3.4 5GS mobile identity</span> ====<br />
<br />
<span style="color:red">The purpose of the 5GS mobile identity information element is to provide either the SUCI, the 5G-GUTI, the IMEI, the IMEISV, the 5G-S-TMSI, the MAC address or the EUI-64.</span><br />
<br />
The 5GS mobile identity information element is coded as shown in figures 9.11.3.4.1, 9.11.3.4.2, 9.11.3.4.3, 9.11.3.4.4, 9.11.3.4.5, 9.11.3.4.6, 9.11.3.4.8 and 9.11.3.4.7, and table 9.11.3.4.1.<br />
<br />
The 5GS mobile identity is a type 6 information element with a minimum length of 4.<br />
<br />
See spec for figures and details...<br />
<br />
<br />
<center>[[Telecommunications info|To Telecommunications info]]</center></div>Paulhttps://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_24.501_notes&diff=3032My 3GPP 24.501 notes2023-07-16T15:15:37Z<p>Paul: /* 4.4.1 General */</p>
<hr />
<div>== 1 Scope ==<br />
3GPP TS 24.501 document specifies the non-access stratum (NAS) procedures in the 5G system (5GS) used by the protocols for:<br />
* mobility management between the user equipment (UE) and the access and mobility management function (AMF) for both 3GPP access and non-3GPP access; and<br />
* session management between the user equipment (UE) and the session management function (SMF) for both 3GPP access and non-3GPP access.<br />
<br />
The 5GS mobility management (5GMM) protocol defined in the present document provides procedures for the control of mobility when the user equipment (UE) is using the NG radio access network (NG-RAN) and/or non-3GPP access network. The 5GMM protocol also provides control of security for the NAS protocols.<br />
<br />
The 5GS session management (5GSM) protocol defined in the present document provides procedures for the handling of 5GS PDU sessions. Together with the bearer control provided by the access stratum, this protocol is used for the control of user-plane resources.<br />
<br />
For both NAS protocols the present document specifies procedures for the support of inter-system mobility between the NG-RAN and the evolved universal terrestrial radio access (E-UTRAN), between the NG-RAN and the non-3GPP access network connected to the EPC, and between the non-3GPP access network connected to the 5G core network (5GCN) and the E-UTRAN.<br />
<br />
For both NAS protocols the present document specifies procedures for the support of mobility between the NG-RAN and the non-3GPP access network connected to the 5GCN.<br />
<br />
In addition, the present document specifies the procedures in the 5GS for UE policy delivery service between the UE and the policy control function (PCF) for both 3GPP access and non-3GPP access.<br />
<br />
The present document is applicable to the UE, the access and mobility management function (AMF), the session management function (SMF), and the PCF in the 5GS.<br />
<br />
The clauses and subclauses in the present document are common for both 3GPP access and non-3GPP access unless it is explicitly stated that they apply to 3GPP access only or non-3GPP access only.<br />
<br />
== 4.1 Overview ==<br />
The <span style="color:red">non-access stratum (NAS) described in 24.501 forms the highest stratum of the control plane between UE and AMF</span> (reference point "N1" see 3GPP TS 23.501) for both 3GPP and non-3GPP access.<br />
<br />
Main functions of the protocols that are part of the NAS are:<br />
* support of mobility of the user equipment (UE) including also common procedures such as authentication, identification, generic UE configuration update and security mode control procedures;<br />
* support of session management procedures to establish and maintain data connectivity between the UE and the data network; and<br />
* NAS transport procedure to provide a transport of SMS, LPP, LCS, UE policy container, SOR transparent container and UE parameters update information payload.<br />
<br />
Principles for the handing of 5GS security contexts and for the activation of ciphering and integrity protection, when a NAS signalling connection is established, are provided in subclause 4.4.<br />
<br />
For the support of the above functions, the following procedures are supplied within this specification:<br />
* elementary procedures for 5GS mobility management in clause 5; and<br />
* elementary procedures for 5GS session management in clause 6.<br />
<br />
Signalling procedures for the control of NAS security are described as part of the 5GMM common procedures in subclause 5.4.<br />
<br />
Complete NAS transactions consist of specific sequences of elementary procedures. Examples of such specific sequences can be found in 3GPP TS 23.502.<br />
<br />
The NAS for 5GS follows the protocol architecture model for layer 3 as described in 3GPP TS 24.007.<br />
<br />
== 4.2 Coordination between the protocols for 5GS mobility management and 5GS session management ==<br />
A 5G system (5GS) session management (5GSM) message is piggybacked in specific 5GS mobility management (5GMM) transport messages. To this purpose, the 5GSM messages can be transmitted in an information element in the 5GMM transport messages. In this case, the UE, the AMF and the SMF execute the 5GMM procedure and the 5GSM procedure in parallel. The success of the 5GMM procedure is not dependent on the success of the piggybacked 5GSM procedure.<br />
<br />
<span style="color:red">The UE can only initiate the 5GSM procedure when there is a 5GMM context established at the UE.</span><br />
<br />
During 5GMM procedures, the UE and the AMF shall suspend the transmission of 5GSM messages, except when:<br />
<ol type="a"><br />
<li>the 5GMM procedure is piggybacking 5GSM messages; or</li><br />
<li>the UE is in 5GMM-CONNECTED mode and a service request procedure for re-establishing user-plane resources of PDU session(s) is initiated without including PDU session status IE or Allowed PDU session status IE. In this case, the UE and the AMF need not suspend the transmission of 5GSM messages related to other PDU session(s) than the one(s) for which the user- plane resources re-establishment is requested.</li><br />
</ol><br />
<br />
If the UE determines to locally release the N1 NAS signalling connection upon receiving an Steering of Roaming (SOR) transparent container during a registration procedure as specified in 3GPP TS 23.122 Annex C.2, the UE shall suspend the transmission of 5GSM messages after sending the REGISTRATION COMPLETE message and until the N1 NAS signalling connection is released to obtain service on a higher priority PLMN, with the exception of the case when the UE has an emergency PDU session.<br />
<br />
A 5GMM message piggybacking a 5GSM message for a PDU session shall be delivered via the access associated with the PDU session, if any, with the following exceptions:<br />
<ol type="a"><br />
<li>the AMF shall send, via 3GPP access, a Downlink (DL) NAS TRANSPORT message piggybacking a downlink 5GSM message of a network-requested 5GSM procedure for a PDU session associated with non-3GPP access if the conditions specified in subclause 5.5.1.3.4 or subclause 5.6.1.4 are met;</li><br />
<li>the UE shall send an UL NAS TRANSPORT message piggybacking a response message to the 5GSM message described in a) via either:</li><br />
# 3GPP access; or<br />
# non-3GPP access if the UE is in 5GMM-CONNECTED mode over non-3GPP access; and<br />
:NOTE: The interaction between the 5GMM sublayer and the 5GSM sublayer to enable the UE to send the UL NAS TRANSPORT message containing the response message via 3GPP access is required. This is achieved via UE implementation.<br />
<li>the UE shall send, via the target access, an Uplink (UL) NAS TRANSPORT message piggybacking a 5GSM message associated with a request type set to "existing PDU session" or "existing emergency PDU session" for handover of an existing PDU session between 3GPP access and non-3GPP access.</li><br />
</ol><br />
<br />
A 5GMM message piggybacking a 5GSM message as a response message to a request message associated with an MA PDU session, shall be delivered via the same access that the initial message was received.<br />
<br />
== UE domain selection ==<br />
<br />
See spec<br />
<br />
== 4.4 NAS security ==<br />
<br />
=== 4.4.1 General ===<br />
This clause describes the principles for the handling of 5G NAS security contexts in the UE and in the AMF, the procedures used for the <span style="color:blue">security protection of NAS messages between the UE and the AMF</span>, and the procedures used for the <span style="color:blue">protection of NAS IEs between the UE and the UDM</span>. Security protection involves integrity protection and ciphering of the 5GMM messages. 5GSM messages are security protected indirectly by being piggybacked by the security protected 5GMM messages (i.e. UL NAS TRANSPORT message and the DL NAS TRANSPORT message).<br />
<br />
The signalling procedures for the control of NAS security are part of the 5GMM protocol and are described in detail in clause 5.<br />
<span style="color:red">:NOTE: ''The use of ciphering in a network is an operator option.'' In this subclause, for the ease of description, it is assumed that ciphering is used, unless explicitly indicated otherwise. Operation of a network without ciphering is achieved by configuring the AMF so that it always selects the "null ciphering algorithm", 5G-EA0.</span><br />
<br />
=== 4.4.2 Handling of 5G NAS security contexts ===<br />
<br />
==== 4.4.2.5 Establishment of secure exchange of NAS messages ====<br />
Secure exchange of NAS messages via a NAS signalling connection is <span style="color:red">usually established by the AMF during the registration procedure by initiating a security mode control procedure</span>. After successful completion of the security mode control procedure, all NAS messages exchanged between the UE and the AMF are sent integrity protected using the current 5G security algorithms, and <span style="color:red">except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered</span> using the current 5G security algorithms.<br />
<br />
==== 4.4.4.2 Integrity checking of NAS signalling messages in the UE ====<br />
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the UE or forwarded to the 5GSM entity, unless the network has established secure exchange of 5GS NAS messages for the NAS signalling connection:<br />
<ol type="a"><br />
<li>IDENTITY REQUEST (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION REQUEST;</li><br />
<li>AUTHENTICATION RESULT;</li><br />
<li>AUTHENTICATION REJECT;</li><br />
<li>REGISTRATION REJECT (if the 5GMM cause is not #76 or #78);</li><br />
<li>DEREGISTRATION ACCEPT (for non switch off); and</li><br />
<li>SERVICE REJECT (if the 5GMM cause is not #76 or #78).</li><br />
</ol><br />
:NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.<br />
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once the secure exchange of NAS messages has been established, the receiving 5GMM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. The processing of the SECURITY MODE COMMAND message that has not successfully passed the integrity check is specified in subclause 5.4.2.5. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.<br />
<br />
==== 4.4.4.3 Integrity checking of NAS signalling messages in the AMF ====<br />
Except the messages listed below, no NAS signalling messages shall be processed by the receiving 5GMM entity in the AMF or forwarded to the 5GSM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:<br />
<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST;</li><br />
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION RESPONSE;</li><br />
<li>AUTHENTICATION FAILURE;</li><br />
<li>SECURITY MODE REJECT;</li><br />
<li>DEREGISTRATION REQUEST; and</li><br />
<li>DEREGISTRATION ACCEPT;</li><br />
</ol><br />
<br />
:NOTE 1: The REGISTRATION REQUEST message is sent by the UE without integrity protection, if the registration procedure is initiated due to an inter-system change in 5GMM-IDLE mode and no current 5G NAS security context is available in the UE. The other messages are accepted by the AMF without integrity protection, as in certain situations they are sent by the UE before security can be activated.<br />
<br />
:NOTE 2: The DEREGISTRATION REQUEST message can be sent by the UE without integrity protection, e.g. if the UE is registered for emergency services and there is no valid 5G NAS security context available, or if due to user interaction a registration procedure is cancelled before the secure exchange of NAS messages has been established. For these cases the network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.<br />
<br />
Integrity protection is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once a current 5G NAS security context exists, until the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF shall process the following NAS signalling messages, even if the MAC included in the message fails the integrity check or cannot be verified, as the 5G NAS security context is not available in the network:<br />
<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST;</li><br />
<li>IDENTITY RESPONSE (if requested identification parameter is SUCI);</li><br />
<li>AUTHENTICATION RESPONSE;</li><br />
<li>AUTHENTICATION FAILURE;</li><br />
<li>SECURITY MODE REJECT;</li><br />
<li>DEREGISTRATION REQUEST;</li><br />
<li>DEREGISTRATION ACCEPT;</li><br />
<li>SERVICE REQUEST; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST;</li><br />
</ol><br />
<br />
:NOTE 3: These messages are processed by the AMF even when the MAC that fails the integrity check or cannot be verified, as in certain situations they can be sent by the UE protected with a 5G NAS security context that is no longer available in the network.<br />
<br />
If a REGISTRATION REQUEST message for initial registration fails the integrity check and it is not a registration request for emergency services, the AMF shall authenticate the subscriber before processing the registration request any further. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the registration procedure is for emergency services see subclause 5.5.1.2.3 and subclause 5.4.1.3.5.<br />
<br />
If a REGISTRATION REQUEST message for mobility and periodic registration update fails the integrity check and the UE provided EPS NAS message container IE which was successfully verified by the source MME, the AMF may create a mapped 5G NAS security context and initiate a security mode control procedure to take the new mapped 5G NAS security context into use; otherwise if the UE has only a non-emergency PDU session established, the AMF shall initiate a primary authentication and key agreement procedure to create a new native 5G NAS security context. Additionally, the AMF shall initiate a security mode control procedure, and include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. For the case when the UE has an emergency PDU session see subclause 5.5.1.3.3 and subclause 5.4.1.3.5.<br />
<br />
If a DEREGISTRATION REQUEST message fails the integrity check, the AMF shall proceed as follows:<br />
:- If it is not a deregistration request due to switch off, and the AMF can initiate an authentication procedure, the AMF should authenticate the subscriber before processing the deregistration request any further.<br />
:- If it is a deregistration request due to switch off, or the AMF does not initiate an authentication procedure for any other reason, the AMF may ignore the deregistration request and remain in state 5GMM-REGISTERED.<br />
:NOTE 4: The network can attempt to use additional criteria (e.g. whether the UE is subsequently still performing periodic registration update or still responding to paging) before marking the UE as 5GMM-DEREGISTERED.<br />
<br />
If a SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message fails the integrity check and the UE has only non-emergency PDU sessions established, the AMF shall send the SERVICE REJECT message with 5GMM cause #9 "UE identity cannot be derived by the network" and keep the 5GMM-context and 5G NAS security context unchanged. For the case when the UE has an emergency PDU session and integrity check fails, the AMF may skip the authentication procedure even if no 5G NAS security context is available and proceed directly to the execution of the security mode control procedure as specified in subclause 5.4.2. Additionally, the AMF shall include the Additional 5G security information IE with the RINMR bit set to "Retransmission of the initial NAS message requested" in the SECURITY MODE COMMAND message as specified in subclause 5.4.2.2. After successful completion of the service request procedure, the network shall perform a local release of all non-emergency PDU sessions. The emergency PDU sessions shall not be released.<br />
<br />
Once the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving 5GMM entity in the AMF shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If any NAS signalling message, having not successfully passed the integrity check, is received, then the NAS in the AMF shall discard that message. If any NAS signalling message is received, as not integrity protected even though the secure exchange of NAS messages has been established, then the NAS shall discard this message.<br />
<br />
=== 4.4.5 Ciphering of NAS signalling messages ===<br />
<span style="color:red">'''The use of ciphering in a network is an operator option subject to AMF configuration'''</span>. <span style="color:red">When operation of the network without ciphering is configured, the AMF shall indicate the use of "null ciphering algorithm" 5G-EA0 (see subclause 9.11.3.34) in the current 5G NAS security context for all UEs</span>. For setting the security header type in outbound NAS messages, the UE and the AMF shall apply the same rules irrespective of whether the "null ciphering algorithm" or any other ciphering algorithm is indicated in the 5G NAS security context.<br />
<br />
<span style="color:red">When the UE establishes a new N1 NAS signalling connection, it shall apply security protection to the initial NAS message as described in subclause 4.4.6.<br />
</span><br />
The UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has been established for an N1 NAS signalling connection. From this time onward, unless explicitly defined, the UE shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.<br />
<br />
The AMF shall start ciphering and deciphering of NAS messages as described in subclause 4.4.2.5. From this time onward, except for the SECURITY MODE COMMAND message, the AMF shall send all NAS messages ciphered until the N1 NAS signalling connection is released, or the UE performs inter-system change to S1 mode.<br />
<br />
Ciphering is never applied directly to 5GSM messages, but to the 5GMM message in which the 5GSM message is included.<br />
<br />
Once the encryption of NAS messages has been started between the AMF and the UE, the receiver shall discard the unciphered NAS messages which shall have been ciphered according to the rules described in this specification.<br />
If the "null ciphering algorithm" 5G-EA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered.<br />
Details of ciphering and deciphering of NAS signalling messages are specified in 3GPP TS 33.501.<br />
<br />
=== 4.4.6 Protection of initial NAS signalling messages ===<br />
The 5GS supports protection of initial NAS messages as specified in 3GPP TS 33.501. <span style="color:red">The protection of initial NAS messages applies to the REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST message</span>, and is achieved as follows:<br />
<ol type="a"><li><span style="color:red">If the UE does not have a valid 5G NAS security context, the UE sends a REGISTRATION REQUEST message including cleartext IEs only.</span> After activating a 5G NAS security context resulting from a security mode control procedure:<br />
<ol><br />
<li>if the UE needs to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message; or</li><br />
<li>if the UE does not need to send non-cleartext IEs, the UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs only) in the NAS message container IE and shall include the NAS message container IE in the SECURITY MODE COMPLETE message.</li></ol></li><br />
<li>If the UE has a valid 5G NAS security context and:<br />
<ol><br />
<li>the UE needs to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE includes the entire REGISTRATION REQUEST or SERVICE REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a REGISTRATION REQUEST or SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li><br />
<li>the UE needs to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message:</li><br />
<ol type="i"><br />
:<li>if CIoT small data container IE is the only non-cleartext IE to be sent, the UE shall cipher the value part of the CIoT small data container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the CIoT small data container IE;</li><br />
:<li>otherwise, the UE includes non-cleartext IEs in the NAS message container IE and shall cipher the value part of the NAS message container IE. The UE shall then send a CONTROL PLANE SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE;</li></ol><br />
<li>the UE does not need to send non-cleartext IEs in a REGISTRATION REQUEST or SERVICE REQUEST message, the UE sends the REGISTRATION REQUEST or SERVICE REQUEST message without including the NAS message container IE; or</li><br />
<li>the UE does not need to send non-cleartext IEs in a CONTROL PLANE SERVICE REQUEST message, the UE sends the CONTROL PLANE SERVICE REQUEST message without including the NAS message container IE and the CIoT small data container IE.</li><br />
</ol><br />
</ol><br />
<span style="color:red">When the initial NAS message is a REGISTRATION REQUEST message, the cleartext IEs are</span>:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* Registration request message identity;<br />
* 5GS registration type;<br />
* ngKSI;<br />
* <span style="color:red">5GS mobile identity</span>;<br />
* UE security capability;<br />
* Additional GUTI;<br />
* UE status;<br />
* EPS NAS message container;<br />
* NID; and<br />
* PLMN with disaster condition.<br />
<br />
When the initial NAS message is a SERVICE REQUEST message, the cleartext IEs are:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* ngKSI;<br />
* Service request message identity;<br />
* Service type; and<br />
* <span style="color:red">5G-S-TMSI</span>.<br />
<br />
When the initial NAS message is a CONTROL PLANE SERVICE REQUEST message, the cleartext IEs are:<br />
* Extended protocol discriminator;<br />
* Security header type;<br />
* Spare half octet;<br />
* ngKSI;<br />
* Control plane service request message identity; and<br />
* Control plane service type.<br />
<br />
When the UE sends a REGISTRATION REQUEST or SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message that includes a NAS message container IE, the UE shall set the security header type of the initial NAS message to "integrity protected".<br />
<br />
When the AMF receives an integrity protected initial NAS message which includes a NAS message container IE, the AMF shall decipher the value part of the NAS message container IE. If the received initial NAS message is a REGISTRATION REQUEST message or a SERVICE REQUEST message, the AMF shall consider the NAS message that is obtained from the NAS message container IE as the initial NAS message that triggered the procedure.<br />
<br />
When the AMF receives a CONTROL PLANE SERVICE REQUEST message which includes a CIoT small data container IE, the AMF shall decipher the value part of the CIoT small data container IE and handle the message as specified in subclause 5.6.1.4.2.<br />
<br />
When the initial NAS message is a DEREGISTRATION REQUEST message, the UE always sends the NAS message unciphered.<br />
<br />
If the UE:<br />
<ol type="a"><br />
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li><br />
<li>selects a PLMN other than Registered PLMN and EPLMN over one access;</li><br />
</ol><br />
the UE shall send an initial NAS message including cleartext IEs only via the access type associated with the newly selected PLMN as described in this subclause for the case when the UE does not have a valid 5G NAS security context.<br />
<br />
If the UE:<br />
<ol type="a"><br />
<li>has 5G-EA0 as a selected 5G NAS security algorithm; and</li><br />
<li>selects a PLMN other than Registered PLMN and EPLMN over one access, and the Registered PLMN or EPLMN is not registering or registered over other access;</li><br />
</ol><br />
the UE shall delete the 5G NAS security context.<br />
<br />
:NOTE: UE deletes the 5G NAS security context only if the UE is not in the connected mode.<br />
<br />
=== 4.4.7 Protection of NAS IEs ===<br />
The network can provide the Steering of Roaming (SOR) transparent container Information Element (IE) during the registration procedure to the User Equipment (UE) in the REGISTRATION ACCEPT message. The SOR transparent container IE is integrity protected by the Home Public Land Mobile Network (HPLMN) or subscribed Standalone Non-Public Network (SNPN) as specified in 3GPP TS 33.501.<br />
<br />
The UE can provide the SOR transparent container IE during the registration procedure to the network in the REGISTRATION COMPLETE message. The SoR-MAC-IUE in the SOR transparent container IE is generated by the UE as specified in 3GPP TS 33.501.<br />
<br />
The network can provide the Payload container IE during the Network-initiated NAS transport procedure to the UE in DL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the Payload container IE is integrity protected by the HPLMN or subscribed SNPN as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the payload container entry contents field of the payload container entry is integrity protected correspondingly.<br />
<br />
The UE can provide the Payload container IE during the UE-initiated NAS transport procedure to the network in UL NAS TRANSPORT message. If the Payload container type IE is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the Payload container IE is generated by the UE as specified in 3GPP TS 33.501. If the Payload container type IE is set to "Multiple payloads" and the payload container type field of the payload container entry is set to "SOR transparent container" or "UE parameters update transparent container", the SoR-MAC-IUE or UPU-MAC-IUE in the payload container entry contents field of the payload container entry is generated by the UE correspondingly.<br />
<br />
== 4.7 NAS over non-3GPP access ==<br />
<br />
See spec for details<br />
<br />
=== 4.7.1 General ===<br />
From the UE's NAS perspective, in general the procedures and messages defined for 5GMM and 5GSM are used over non-3GPP access as over 3GPP access. However, a number of aspects are different as described in the following subclauses.<br />
<br />
=== 4.7.2 5GS mobility management (5GMM) aspects ===<br />
<br />
==== 4.7.2.1 General ====<br />
The mobility management procedures defined over 3GPP access are re-used over non-3GPP access with certain exceptions. The list goes from a) to s), see spec for details.<br />
<br />
==== 4.7.2.2 Establishment cause for non-3GPP access ====<br />
When establishment of an N1 NAS signalling connection over non-3GPP access is initiated, the UE shall do certain things. See spec for details.<br />
<br />
<br />
=== 4.7.3 5GS session management (5GSM) aspects ===<br />
The session management procedures defined over 3GPP access are re-used over non-3GPP access with the following exceptions:<br />
<ol type="a"><br />
<li>Serving PLMN rate control does not apply for non-3GPP access;</li><br />
<li>Small data rate control does not apply for non-3GPP access;</li><br />
<li>Handling of 5GSM cause value #82 "maximum data rate per UE for user-plane integrity protection is too low" does not apply for non-3GPP access;</li><br />
<li>MBS does not apply for non-3GPP access; and</li><br />
<li>Support of redundant PDU sessions does not apply for non-3GPP access.</li><br />
</ol><br />
<br />
=== 4.7.4 Limited service state over non-3GPP access ===<br />
<br />
There are a number of situations in which the UE is unable to obtain normal service from a PLMN over non-3GPP access and the UE enters the limited service state over non-3GPP access. These include:<br />
<ol type="a"><br />
<li>no Universal Subscriber Identity Module (USIM) in the Mobile Equipment (ME);</li><br />
<li>an "illegal UE" or "illegal ME" is received when registration, network-initiated de-registration or service request is performed (any USIM in the ME is then considered "invalid");</li><br />
<li>a "5GS services not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "PLMN not allowed" is received when registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "Tracking area not allowed" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>a "Roaming not allowed in this tracking area" is received when a registration, network-initiated de-registration or service request is performed;</li><br />
<li>void; or</li><br />
<li>a "Serving network not authorized" is received when a registration or service request is performed.</li><br />
</ol><br />
In limited service state with a valid USIM in the UE, the network selection is performed as defined in 3GPP TS 24.502.<br />
<br />
With the exception of performing initial registration for emergency services, no registration requests are made until a valid USIM is present. For registration for emergency services, the PLMN of the current N3IWF or TNGF is considered as the selected PLMN for the duration the UE is registered for emergency services.<br />
<br />
=== 4.7.5 NAS signalling using trusted WLAN access network ===<br />
<br />
A trusted WLAN interworking function (TWIF) provides functionalities for a non-5G capable over WLAN (N5CW) device to access 5GCN, including:<br />
<ol type="a"><br />
<li>NAS signalling over N1 NAS signalling connection with AMF; and</li><br />
<li>PDU session establishment, modification and release on behalf of the N5CW device, over N2 connection with the AMF.</li><br />
</ol><br />
The TWIF registers on behalf of the N5CW device to an AMF according to subclause 5.5.1.3 by populating the parameters for the registration by using implementation specific default values which are the same for N5CW devices.<br />
<br />
The TWIF may request to establish a PDU session as specified in subclause 6.4.1.2 on behalf of the N5CW device upon receipt of an IP configuration request from the N5CW device by populating either all the required parameters or part of the required parameters for the PDU session establishment by using implementation specific default values from the TWIF's configuration. Only one PDU session is supported when N5CW device accessing 5GC via the TWIF.<br />
<br />
:NOTE 1: If part of the required parameters for the PDU session establishment is provided by the TWIF, the remaining of the required parameters are determined by the AMF or the SMF based on the N5CW device's subscription information.<br />
Upon loss of the IP address of the N5CW device, the TWIF acting on behalf of the N5CW device shall initiate the UE-requested PDU session release procedure as defined in subclause 6.4.3.<br />
<br />
:NOTE 2: The established PDU session on behalf of the N5CW device can be modified by the TWIF or the network.<br />
<br />
== 4.8 Interworking with E-UTRAN connected to EPC ==<br />
<br />
=== 4.8.1 General ===<br />
In order to interwork with E-UTRAN connected to EPC, the UE supporting both S1 mode and N1 mode can operate in single-registration mode or dual-registration mode (see 3GPP TS 23.501). Support of single-registration mode is mandatory for UEs supporting both S1 mode and N1 mode.<br />
<br />
During the EPS attach procedure (see 3GPP TS 24.301) or initial registration procedure (see subclause 5.5.1.2), the mode for interworking is selected if the UE supports both S1 mode and N1 mode, and the network supports interworking. The mode for interworking may also be selected during the EPS tracking area updating procedure (see 3GPP TS 24.301) or registration procedure for mobility and periodic registration update (see subclause 5.5.1.3).<br />
<br />
For interworking between E-UTRAN connected to EPC and TNGF or N3IWF connected to 5GCN, the UE shall operate as specified in either subclause 4.8.2.3 or subclause 4.8.3. Which subclause the UE follows is chosen by the UE irrespective of the interworking without N26 interface indicator.<br />
<br />
=== 4.8.2 Single-registration mode ===<br />
See spec for details...<br />
<br />
=== 4.8.3 Dual-registration mode ===<br />
<br />
If both 5G Mobility Management (5GMM) and EPS Mobility Management (EMM) are enabled, a UE, operating in the dual-registration mode shall maintain independent contexts for 5GMM and EMM and this includes independent lists of equivalent PLMNs. Coordination between 5GMM and EMM is not needed, except as specified in the present subclause, subclause 5.1.5 and 5.3.13A.<br />
<br />
For dual-registration mode the following applies:<br />
<ol type="a"><br />
<li>a UE operating in the dual-registration mode may register to N1 mode only, S1 mode only, or to both N1 mode and S1 mode;</li><br />
<li>when the UE decides to operate in dual-registration mode (see subclause 5.5.1.2.4), NAS informs the lower layers about this;</li><br />
<li>if a UE is registered in N1 mode only, then for registration in S1 mode the UE shall use:</li><br />
# the same PLMN to which it is registered in N1 mode; or<br />
# an equivalent PLMN; and<br />
<li>if a UE is registered in S1 mode only, then for registration in N1 mode the UE shall use:</li><br />
# the same PLMN to which it is registered in S1 mode; or<br />
# an equivalent PLMN.<br />
</ol><br />
:NOTE 1: It is up to UE implementation how to handle the case when the UE is registered in both N1 mode and S1 mode and the PLMNs to which the UE is registered, are not equivalent, e.g. search for a PLMN which is the same or equivalent to any of the registered ones.<br />
<br />
When no PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure with PDN connection establishment if EMM-REGISTERED without PDN connection is not supported by the MME. If EMM-REGISTERED without PDN connection is supported by the MME, the UE may initiate either the EPS attach procedure without PDN connection establishment or the attach procedure with PDN connection establishment.<br />
<br />
When at least one PDU session is active and the UE has not registered to S1 mode yet, the UE may initiate the EPS attach procedure. If necessary, the UE may transfer an active PDU session from N1 mode to S1 mode by initiating the EPS attach procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message. After successfully attached in S1 mode, if necessary, the UE may transfer other active PDU sessions from N1 mode to S1 mode by initiating the PDN connectivity procedure with request type set to "handover" in the PDN CONNECTIVITY REQUEST message.<br />
<br />
:NOTE 2: It is up to UE implementation to determine which active PDU session is transferred from N1 mode to S1 mode.<br />
<br />
When the UE has not registered to N1 mode, the UE may initiate the initial registration procedure. After successfully registered in N1 mode, if necessary, the UE may transfer one or more active PDN connections from S1 mode to N1 mode by initiating the PDU session establishment procedure with request type set to "existing PDU session".<br />
<br />
:NOTE 3: It is up to UE implementation to determine which active PDN connection is transferred from S1 mode to N1 mode.<br />
<br />
If the MME supports EMM-REGISTERED without PDN connection, the UE that transferred all PDN connections to the 5GS, may stay in state EMM-REGISTERED. Otherwise, the UE shall enter state EMM-DEREGISTERED upon transferring all PDN connection to the 5GS.<br />
<br />
:NOTE 4: When the UE has registered in both N1 mode and S1 mode, it is up to UE implementation to maintain the registration update to date in both N1 mode and S1 mode.<br />
<br />
See subclause 6.1.4 for coordination between 5GSM and ESM.<br />
<br />
See subclause 4.8.2.3.2 for interworking between TNGF or N3IWF connected to 5GCN and E-UTRAN.<br />
<br />
=== 4.8.4 Core Network selection for UEs not using Cellular Internet of Things (CIoT) 5GS optimizations ===<br />
If the UE is capable of both N1 mode and S1 mode, when the UE needs to use one or more functionalities not supported in 5GS but supported in EPS and the UE is in 5GMM-IDLE mode, the UE may disable the N1 mode capability for 3GPP access (see subclause 4.9.2).<br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN without also providing an indication that a target core network type was received from the NG-RAN, the UE shall select a core network type (EPC or 5GCN) based on the PLMN selection procedures as specified in 3GPP TS 23.122 and provide the selected core network type information to the lower layer during the initial registration procedure.<br />
<br />
If the UE is capable of both N1 mode and S1 mode and the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN and an indication of whether the network supports IMS emergency services via either EPC or 5GCN or both (see 3GPP TS 36.331 [25A]), the UE selects a core network type (EPC or 5GCN) as specified in 3GPP TS 23.167 [6] annex H.2 for initiating emergency calls when in the state 5GMM-DEREGISTERED.LIMITED-SERVICE or EMM-DEREGISTERED.LIMITED-SERVICE.<br />
:NOTE 1: If the PLMN selection information provisioned in the USIM does not contain any prioritization between E-UTRAN and NG-RAN for a PLMN, which core network type to select for that PLMN is up to UE implementation.<br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN with:<br />
# an indication that target core network type EPC was received from the NG-RAN, the UE shall select the EPC and proceed with the appropriate EMM procedure as specified in 3GPP TS 24.301; or<br />
# an indication that target core network type 5GCN was received from the NG-RAN, the UE shall select the 5GCN and proceed with the appropriate 5GMM procedure.<br />
:NOTE 2: The NG-RAN can provide a target core network type to the UE during RRC connection release with redirection (see 3GPP TS 36.331 and 3GPP TS 38.331).<br />
<br />
=== 4.8.4A Core Network selection and redirection for UEs using CIoT optimizations ===<br />
<br />
==== 4.8.4A.1 Core network selection ====<br />
A UE that supports CIoT optimizations performs core network selection (i.e. it selects EPC or 5GCN) if the lower layers have provided an indication that the current E-UTRA cell is connected to both EPC and 5GCN as specified in 3GPP TS 23.501.<br />
<br />
When selecting a PLMN as described in 3GPP TS 23.122, the UE shall select a core network type (EPC or 5GCN) based on:<br />
<ol type="a"><br />
<li>indication from the lower layers about the CIoT EPS optimizations supported in EPC;</li><br />
<li>indication from the lower layers about the CIoT 5GS optimizations supported in 5GCN;</li><br />
<li>the CIoT EPS optimizations supported by the UE;</li><br />
<li>the CIoT 5GS optimizations supported by the UE;</li><br />
<li>the UE's preferred CIoT network behaviour for EPC; and</li><br />
<li>the UE's preferred CIoT network behaviour for 5GCN.</li><br />
</ol><br />
<br />
The UE shall provide the selected core network type information to the lower layer during the initial registration procedure.<br />
<br />
==== 4.8.4A.2 Redirection of the UE by the core network ====<br />
The network that supports CIoT optimizations can redirect a UE between EPC and 5GCN as specified in subclause 5.31.3 of 3GPP TS 23.501. The network can take into account the UE's N1 mode capability or S1 mode capability, the CIoT network behaviour supported and preferred by the UE or the CIoT network behaviour supported by the network to determine the redirection.<br />
<br />
:NOTE: It is assumed that the network would avoid redirecting the UE back and forth between EPC and 5GCN.<br />
<br />
The network redirects the UE to EPC by rejecting the registration request or service request with the 5GMM cause #31 "Redirection to EPC required" as specified in subclause 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5. Upon receipt of reject message, the UE disables the N1 mode capability for 3GPP access as specified in subclause 4.9.2 and enables the E-UTRA capability if it was disabled in order to move to EPC.<br />
<br />
When there is no ongoing registration procedure or service request procedure for a UE in 5GMM-CONNECTED mode, if the AMF determines to redirect the UE to EPC, the AMF shall initiate the generic UE configuration update procedure to indicate registration requested and release of the N1 NAS signalling connection not requested as described in subclause 5.4.4. The network then redirects the UE to EPC by rejecting the registration request as specified in subclause 5.5.1.3.5.<br />
<br />
The network that supports CIoT optimizations can also redirect a UE from EPC to 5GCN as specified in subclause 5.3.19.2 of 3GPP TS 24.301.<br />
<br />
== 4.9 Disabling and re-enabling of UE's N1 mode capability ==<br />
<br />
=== 4.9.1 General ===<br />
<br />
The UE shall re-enable the N1 mode capability when the UE powers off and powers on again, the USIM is removed or an entry of the "list of subscriber data" with the SNPN identity of the SNPN is updated.<br />
<br />
=== 4.9.2 Disabling and re-enabling of UE's N1 mode capability for 3GPP access ===<br />
<br />
The UE shall only disable the N1 mode capability for 3GPP access when in 5GMM-IDLE mode.<br />
<br />
When the UE is disabling the N1 mode capability for 3GPP access for a PLMN not due to redirection to EPC, it should proceed as follows:<br />
<ol type="a"><br />
<li>select an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs, if the UE supports S1 mode and the UE has not disabled its E-UTRA capability as specified in 3GPP TS 24.301;</li><br />
<li>if an E-UTRA cell connected to EPC of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, the UE does not support S1 mode or the UE has disabled its E-UTRA capability as specified in 3GPP TS 24.301, the UE may select another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs that the UE supports;</li><br />
<li>if another RAT of the registered PLMN or a PLMN from the list of equivalent PLMNs cannot be found, then enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH, or the UE does not have a registered PLMN, then enter the state 5GMM-DEREGISTERED.PLMN-SEARCH and perform PLMN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this PLMN selection. As an implementation option, if the UE does not have a registered PLMN, instead of performing PLMN selection, the UE may select another RAT of the selected PLMN if the UE has chosen a PLMN and the RAT is supported by the UE; or</li><br />
<li>if no other allowed PLMN and RAT combinations are available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered PLMN, and may periodically scan for another PLMN and RAT combination which can provide EPS services or non-EPS services (if the UE supports EPS services or non-EPS services). How this periodic scanning is done, is UE implementation dependent.</li><br />
</ol><br />
When the UE is disabling the N1 mode capability for 3GPP access for an SNPN, it should proceed as follows:<br />
<ol type="a"><br />
<li>enter the state 5GMM-REGISTERED.PLMN-SEARCH or 5GMM-DEREGISTERED.PLMN-SEARCH and perform SNPN selection as specified in 3GPP TS 23.122. If disabling of the N1 mode capability for 3GPP access was not due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off, the UE may re-enable the N1 capability for this SNPN selection; or</li><br />
<li>if no other SNPN is available, then the UE may re-enable the N1 mode capability for 3GPP access and indicate to lower layers to remain camped in NG-RAN of the registered SNPN.</li><br />
</ol><br />
<br />
When the UE is disabling the N1 mode capability upon receiving cause value #31 "Redirection to EPC required" as specified in subclauses 5.5.1.2.5, 5.5.1.3.5 and 5.6.1.5, it should proceed as follows:<br />
<ol type="a"><br />
<li>If the UE is in NB-N1 mode:</li><br />
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable NB-IoT cell connected to EPC according to 3GPP TS 36.304;<br />
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or<br />
# if lower layers cannot find a suitable NB-IoT cell connected to EPC or there is no suitable NB-IoT cell connected to EPC which supports CIoT EPS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.<br />
<li>If the UE is in WB-N1 mode:</li><br />
# if lower layers do not provide an indication that the current E-UTRA cell is connected to EPC or lower layers do not provide an indication that the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, search for a suitable E-UTRA cell connected to EPC according to 3GPP TS 36.304;<br />
# if lower layers provide an indication that the current E-UTRA cell is connected to EPC and the current E-UTRA cell supports CIoT EPS optimizations that are supported by the UE, then perform a core network selection to select EPC as specified in subclause 4.8.4A.1; or<br />
# if lower layers cannot find a suitable E-UTRA cell connected to EPC or there is no suitable E-UTRA cell connected to EPC which supports CIoT EPS optimizations that are supported by the UE, the UE, as an implementation option, may indicate to lower layers to remain camped in E-UTRA cell connected to 5GCN, may then start an implementation-specific timer and enter the state 5GMM-REGISTERED.LIMITED-SERVICE. The UE may re-enable the N1 mode capability for 3GPP access at expiry of the implementation-specific timer, if the timer had been started, and may then proceed with the appropriate 5GMM procedure.<br />
</ol><br />
<br />
When the UE supporting both N1 mode and S1 mode needs to stay in E-UTRA connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional handover or cell reselection from E-UTRA connected to EPC to NG-RAN connected to 5GCN, the UE operating in single-registration mode shall disable the N1 mode capability for 3GPP access and:<br />
<ol type="a"><br />
<li>shall set the N1mode bit to "N1 mode for 3GPP access not supported" in the UE network capability IE (see 3GPP TS 24.301) of the ATTACH REQUEST message and the TRACKING AREA UPDATE REQUEST message in EPC; and</li><br />
<li>the UE NAS layer shall indicate the access stratum layer(s) of disabling of the N1 mode capability for 3GPP access.</li><br />
</ol><br />
<br />
If the UE is required to disable the N1 mode capability for 3GPP access and select E-UTRA or another RAT, and the UE is in the 5GMM-CONNECTED mode,<br />
* if the UE has a persistent PDU session, then the UE waits until the radio bearer associated with the persistent PDU session has been released;<br />
* otherwise the UE shall locally release the established NAS signalling connection;<br />
<br />
and enter the 5GMM-IDLE mode before selecting E-UTRA or another RAT.<br />
<br />
If the UE is disabling its N1 mode capability for 3GPP access before selecting E-UTRA or another RAT, the UE shall not perform the UE-initiated de-registration procedure of subclause 5.5.2.2.<br />
<br />
The UE shall re-enable the N1 mode capability for 3GPP access when the UE performs PLMN or SNPN selection over 3GPP access, unless<br />
* disabling of the N1 mode capability for 3GPP access was due to a UE-initiated de-registration procedure for 5GS services over 3GPP access not due to switch-off; or<br />
* the UE has already re-enabled the N1 mode capability for 3GPP access when performing items c) or d) above.<br />
<br />
If the disabling of N1 mode capability for 3GPP access was due to IMS voice is not available over 3GPP access and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for 3GPP access when the UE's usage setting is changed from "voice centric" to "data centric", as specified in subclauses 4.3.3.<br />
<br />
The UE should memorize the identity of the PLMN or SNPN where N1 mode capability for 3GPP access was disabled and should use that stored information in subsequent PLMN or SNPN selections as specified in 3GPP TS 23.122.<br />
<br />
If the disabling of N1 mode capability for 3GPP access was due to successful completion of an emergency services fallback, the criteria to enable the N1 mode capability again are UE implementation specific.<br />
<br />
The UE shall disable the N1 mode capability for 3GPP access if requested by the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229). If the UE disabled the N1 mode capability for 3GPP access based on the request from the upper layers (e.g. see subclause U.2.2.6.4 in 3GPP TS 24.229), the criteria to re-enable the N1 mode capability for 3GPP access after the completion of an emergency service are UE implementation specific.<br />
<br />
If the N1 mode capability for 3GPP access was disabled due to the UE initiated de-registration procedure for 3GPP access or for 3GPP access and non-3GPP access and the UE is operating in single-registration mode (see subclause 5.5.2.2.3), upon request of the upper layers to re-register for 5GS services over 3GPP access the UE shall enable the N1 mode capability for 3GPP access again.<br />
<br />
As an implementation option, the UE may start a timer for enabling the N1 mode capability for 3GPP access when the UE's registration attempt counter reaches 5 and the UE disables the N1 mode capability for 3GPP access for cases described in subclauses 5.5.1.2.7 and 5.5.1.3.7. The UE should memorize the identity of the PLMNs where N1 mode capability for 3GPP access was disabled. On expiry of this timer:<br />
* if the UE is in Iu mode or A/Gb mode and is in idle mode as specified in 3GPP TS 24.008 on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access;<br />
* if the UE is in Iu mode and a PS signalling connection exists, but no RR connection exists, the UE may abort the PS signalling connection before enabling the N1 mode capability for 3GPP access; and<br />
* if the UE is in S1 mode and is in EMM-IDLE mode as specified in 3GPP TS 24.301, on expiry of the timer, the UE should enable the N1 mode capability for 3GPP access.<br />
<br />
If the UE is in Iu mode or A/Gb mode and an Radio Resource (RR) connection exists, the UE should delay enabling the N1 mode capability for 3GPP access until the RR connection is released. If the UE is in S1 mode and is in EMM-CONNECTED mode as specified in 3GPP TS 24.301, the UE should delay enabling the N1 mode capability for 3GPP access until the NAS signalling connection in S1 mode is released.<br />
<br />
<pre>A Interface between a BSS and a 2G MSC<br />
Gb Interface between a BSS and a 2G SGSN<br />
Iu-cs Interface between a BSS and a 3G MSC<br />
Iu-ps Interface between a BSS and a 3G SGSN<br />
Iur-g Interface between two BSSs<br />
Um Interface between MS and BSS<br />
<br />
Source: 3GPP TS 43.501</pre><br />
<br />
The UE may disable the N1 mode capability for currently camped PLMN or SNPN over 3GPP access (see 3GPP TS 23.122) if no network slice is available for the camped PLMN or SNPN.<br />
<br />
If the UE attempts to establish an emergency PDU session in a PLMN where N1 mode capability was disabled due to the UE's registration attempt counter have reached 5, the UE may enable N1 mode capability for that PLMN memorized by the UE.<br />
<br />
:NOTE: If N1 mode capability is disabled due to the UE's registration attempt counter reaches 5, the value of the timer for re-enabling N1 mode capability is recommended to be the same as the value of T3502 which follows the handling specified in subclause 5.3.8.<br />
<br />
=== 4.9.3 Disabling and re-enabling of UE's N1 mode capability for non-3GPP access ===<br />
<br />
When the UE disables the N1 mode capability for non-3GPP access, the UE NAS layer shall not initiate any 5GS NAS procedures towards the network over non-3GPP access.<br />
<br />
When the UE supporting both N1 mode and S1 mode needs to stay in non-3GPP access connected to EPC (e.g. due to the domain selection for UE originating sessions as specified in subclause 4.3.2), in order to prevent unintentional selection of a non-3GPP access network connected to 5GCN, the UE operating in single-registration mode shall not transfer any PDN connection to a non-3GPP access network connected to the 5GCN.<br />
<br />
If the disabling of N1 mode capability for non-3GPP access was due to IMS voice is not available over non-3GPP access in 5GS and the UE's usage setting is "voice centric", the UE shall re-enable the N1 mode capability for non-3GPP access when the UE's usage setting is changed from "voice centric" to "data centric" as specified in subclauses 4.3.3.<br />
<br />
The UE shall re-enable the N1 mode capability for non-3GPP access when a new PLMN or SNPN is selected over non-3GPP access.<br />
<br />
:NOTE: In SNPN, the term "UE's N1 mode capability for non-3GPP access" in this subclause refers to the UE's N1 mode capability to access SNPN services via a PLMN.<br />
<br />
The UE may disable the N1 mode capability for the currently camped PLMN or SNPN over non-3GPP access if no network slice is available for the camped PLMN or SNPN.<br />
<br />
As an implementation option, the UE may start a timer for re-enabling the N1 mode capability for non-3GPP access, after the N1 mode capability for non-3GPP access was disabled. On the expiry of this timer, the UE should re-enable the N1 mode capability for non-3GPP access.<br />
<br />
== 4.11 UE configuration parameter updates ==<br />
<br />
The 5GS in a PLMN supports updating UE parameters via NAS signalling. The feature enables the HPLMN to securely and dynamically re-configure the UE configuration parameters stored on the USIM and the ME.<br />
<br />
See spec for details...<br />
<br />
== 4.13 Support of NAS signalling using wireline access network ==<br />
A 5G-RG, a W-AGF acting on behalf of an FN-RG or a W-AGF acting on behalf of an N5GC device can use wireline access network to access the 5GCN by using NAS signalling procedures as described in 3GPP TS 23.501, 3GPP TS 23.502 and 3GPP TS 23.316.<br />
<br />
Wireline access is a type of non-3GPP access.<br />
<br />
A 5G-RG simultaneously connected to the same 5GCN of a PLMN over a 3GPP access and a wireline access is connected to a single AMF.<br />
<br />
5G-RG maintains the N1 NAS signalling connection with the AMF over the wireline access network after all the PDU sessions for the 5G-RG over that access have been released or handed over to 3GPP access.<br />
<br />
See spec for details...<br />
<br />
== 4.14 Non-public network (NPN) ==<br />
=== 4.14.1 General ===<br />
Two types of NPN can be deployed using 5GS: SNPN (see subclause 4.14.2) and PNI-NPN (see subclause 4.14.3).<br />
<br />
==== 4.14.2 Stand-alone non-public network ====<br />
If the UE is not SNPN enabled, the UE is always considered to be not operating in SNPN access operation mode. If the UE is SNPN enabled, the UE can operate in SNPN access operation mode. Details of activation and deactivation of SNPN access operation mode at the SNPN enabled UE are up to UE implementation.<br />
<br />
The functions and procedures of NAS described in the present document are applicable to an SNPN and an SNPN enabled UE unless indicated otherwise.<br />
<br />
See spec for details...<br />
<br />
=== 4.14.3 Public network integrated non-public network (PNI-NPN) ===<br />
<br />
A PNI-NPN is made available by means of e.g. dedicated DNNs or by one or more S-NSSAIs allocated for it. A CAG can be optionally used in order to prevent UEs not allowed to access a PNI-NPN from accessing the PNI-NPN.<br />
<br />
See spec for details...<br />
<br />
== 4.16 UE radio capability signalling optimization ==<br />
<br />
See spec for details...<br />
<br />
== 4.17 5GS mobility management in NB-N1 mode ==<br />
<br />
See spec for details...<br />
<br />
== 4.19 5GS mobility management in WB-N1 mode for IoT ==<br />
<br />
See spec for details...<br />
<br />
== 4.20 5GS session management in WB-N1 mode for IoT ==<br />
<br />
See spec for details...<br />
<br />
== 4.23 NAS over Non-Terrestrial Network ==<br />
<br />
See spec for details...<br />
<br />
== 4.24 Minimization of service interruption (MINT) ==<br />
<br />
The UE and the network may support Minimization of service interruption (MINT). MINT aims to enable a UE to obtain service from a PLMN offering disaster roaming service when a disaster condition applies to the UE's determined PLMN with disaster condition.<br />
<br />
If the UE supports MINT, the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "list of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range provisioned by the network, if available, are stored in the non-volatile memory in the ME as specified in annex C and are kept when the UE enters 5GMM-DEREGISTERED state. Annex C specifies condition under which the indication of whether disaster roaming is enabled in the UE, the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN', the one or more "lists of PLMN(s) to be used in disaster condition", disaster roaming wait range and disaster return wait range stored in the ME are deleted.<br />
<br />
See spec for details...<br />
<br />
== 4.25 Support of MUSIM features ==<br />
<pre>MUSIM UE: A UE with multiple valid Universal Subscriber Identity Modules (USIMs), capable of initiating and maintaining simultaneous separate registration states over 3GPP access with PLMN(s) using identities and credentials associated with those USIMs and supporting one or more of the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control (see 3GPP TS 23.501).<br />
<br />
Source: 3GPP TS 24.501</pre><br />
<br />
A network and a MUSIM UE may support one or more of the MUSIM features (i.e. the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction and the paging timing collision control).<br />
<br />
If MUSIM UE supports one or more MUSIM features, the UE indicates support of one or more MUSIM features (except for the paging timing collision control) during the registration procedure. If the UE has indicated support of the N1 NAS signalling connection release or the reject paging request or both and the UE supports the paging restriction, the UE indicates support of the paging restriction.<br />
<br />
If the UE indicates support of one or more MUSIM features and the network decides to accept one or more MUSIM features, the network indicates the support of one or more MUSIM features during the registration procedure. The network only indicates the support of the paging restriction together with the support of either N1 NAS signalling connection release or the reject paging request.<br />
<br />
The network does not indicate support for any MUSIM feature to the UE during the registration for emergency services.<br />
<br />
If a UE stops fulfilling the condition to be considered a MUSIM UE as defined in subclause 3.1, and the UE has negotiated support of one or more MUSIM features, then the UE shall initiate a registration procedure for mobility and periodic registration update to indicate that all the MUSIM features are not supported (except for the paging timing collision control) as specified in subclause 5.5.1.3.<br />
<br />
A MUSIM UE operating in NB-N1 mode or in WB-N1 mode CE mode B does not indicate the support for paging indication for voice services during the registration procedure towards the network.<br />
<br />
== 5.1 Overview ==<br />
<br />
=== 5.1.1 General ===<br />
<br />
The main function of the 5GS mobility management (5GMM) sublayer is to support the identification, security, mobility of a UE as well as generic message transport.<br />
<br />
A further function of the 5GMM sublayer is to provide connection management services to the other sublayer(s).<br />
<br />
:NOTE: In a satellite NG-RAN access, a GNSS fix time in lower layers can delay transmission of an initial UL NAS message by up to 100 seconds (GNSS cold state).<br />
<br />
=== 5.1.2 Types of 5GMM procedures ===<br />
Depending on how they can be initiated, three types of 5GMM procedures can be distinguished:<br />
* 5GMM common procedures<br />
* 5GMM specific procedures<br />
* 5GMM connection management procedures<br />
<br />
Three types of 5GMM procedures broken out...<br />
<br />
<ol type="a"><br />
<li>5GMM common procedures:<br />
<br />
5GMM common procedure can always be initiated when the UE is in 5GMM-CONNECTED mode. The procedures belonging to this type are:</li><br />
<ol type="1"><br />
<li>Initiated by the network:</li><br />
<ol type="i"><br />
<li>network-initiated NAS transport;</li><br />
<li>primary authentication and key agreement;</li><br />
<li>security mode control;</li><br />
<li>generic UE configuration update;</li><br />
<li>identification; and</li><br />
<li>network slice-specific authentication and authorization;</li><br />
</ol><br />
<li>Initiated by the UE:<br />
<br />
:UE-initiated NAS transport.</li><br />
<li>Initiated by the UE or the network and used to report certain error conditions detected upon receipt of 5GMM protocol data:<br />
<br />
:5GMM status.</li><br />
</ol><br />
<li>5GMM specific procedures:<br />
<br />
:At any time only one UE initiated 5GMM specific procedure can be running for each of the access network(s) that the UE is camping in. The procedures belonging to this type are:</li><br />
<ol type="1"><br />
<li>Initiated by the UE and used e.g. to register to the network for 5GS services and establish a 5GMM context, to update the location/parameter(s) of the UE:<br />
<br />
:registration.</li><br />
<li>Initiated by the UE or the network and used to deregister from the network for 5GS services and to release a 5GMM context:<br />
<br />
:de-registration.</li><br />
<li>Initiated by the UE and used to deregister from the network for 5GS services and to release a 5GMM context:<br />
<br />
:eCall inactivity procedure.</li><br />
</ol><br />
<li>5GMM connection management procedures:</li><br />
<ol type="1"><br />
<li>Initiated by the UE and used to establish a secure connection to the network or to request the resource reservation for sending data, or both:<br />
<br />
:service request.<br />
<br />
The service request procedure can only be initiated if no UE initiated 5GMM specific procedure is ongoing for each of the access network(s) that the UE is camping in.</li><br />
<li>Initiated by the network and used to request the establishment of an N1 NAS signalling connection or to request re-establishment of user-plane resources for the PDU session(s) associated with 3GPP access or to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access; not applicable for the non-3GPP access network:<br />
<br />
:paging.</li><br />
<li>Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with non-3GPP access over 3GPP access or to deliver 5GSM downlink signalling messages associated with non-3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over 3GPP access and in 5GMM-IDLE mode over non-3GPP access; or<br><br><br />
<br />
Initiated by the network and used to request re-establishment of user-plane resources of the PDU session(s) associated with 3GPP access over 3GPP access or to deliver downlink signalling associated with 3GPP access over 3GPP access, when the UE is in 5GMM-CONNECTED mode over non-3GPP access, and when the UE is in 5GMM-IDLE mode over 3GPP access and not in MICO mode:<br />
<br />
:notification.</li><br />
</ol><br />
</ol><br />
<br />
:NOTE 1: In NB-N1 mode, the UE NAS using 5GS services with control plane CIoT 5GS optimization can wait for the lower layers to complete the transmission of the previous UL NAS TRANSPORT messages carrying control plane user data before providing subsequent NAS messages. Other implementations are possible.<br />
<br />
:NOTE 2: When providing NAS messages to the lower layers for transmission, the UE NAS using 5GS services with control plane CIoT 5GS optimization can prioritize sending NAS signalling messages over the UL NAS TRANSPORT messages carrying control plane user data. How the UE performs this prioritization is implementation specific.<br />
<br />
=== 5.1.3 5GMM sublayer states ===<br />
<br />
==== 5.1.3.1 General ====<br />
<br />
In the following subclauses, the 5GS mobility management (5GMM) sublayer of the UE and the network is described by means of different state machines. The 5GMM sublayer states is managed per access type independently, i.e. 3GPP access or non-3GPP access. In subclause 5.1.3.2, the states of the 5GMM sublayer are introduced.<br />
<br />
===== 5.1.3.2.1 5GMM sublayer states in the UE =====<br />
<br />
See spec, lots of info...<br />
<br />
===== 5.1.3.2.2 5GS update status in the UE =====<br />
<br />
In order to describe the detailed UE behaviour, the 5GS update (5U) status pertaining to a specific subscriber is defined.<br />
<br />
If the UE is not operating in SNPN access operation mode (see 3GPP TS 23.501), the 5GS update status is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.<br />
<br />
If the UE is operating in SNPN access operation mode, the 5GS update status for each SNPN whose SNPN identity is included in the "list of subscriber data" configured in the ME (see 3GPP TS 23.122) is stored in the non-volatile memory in the ME as described in annex C.<br />
<br />
The 5GS update status value is changed only after the execution of a registration, network-initiated de-registration, 5GS based primary authentication and key agreement, service request, paging procedure or due to change in the current TAI which does not belong to the current registration area while T3346 is running.<br />
<br />
:5U1: UPDATED<br />
::The last registration attempt was successful.<br />
:5U2: NOT UPDATED<br />
::The last registration or service request attempt failed procedurally, e.g. no response or reject message was received from the AMF.<br />
:5U3: ROAMING NOT ALLOWED<br />
::The last registration, service request, or registration for mobility or periodic registration update attempt was correctly performed, but the answer from the AMF was negative (because of roaming or subscription restrictions).<br />
<br />
===== 5.1.3.2.3 5GMM sublayer states in the network side =====<br />
<br />
There are four 5GMM sublayer states in the network side.<br />
<br />
; 5GMM-DEREGISTERED : In the state 5GMM-DEREGISTERED, no 5GMM context has been established or the 5GMM context is marked as deregistered. The UE is deregistered. The network may answer to an initial registration procedure initiated by the UE. The network may also answer to a de-registration procedure initiated by the UE.<br />
; 5GMM-COMMON-PROCEDURE-INITIATED : The network enters the state 5GMM-COMMON-PROCEDURE-INITIATED, after it has started a common 5GMM procedure and is waiting for a response from the UE.<br />
; 5GMM-REGISTERED : In the state 5GMM-REGISTERED, a 5GMM context has been established. Additionally, one or more PDU session(s) may be established at the network.<br />
; 5GMM-DEREGISTERED-INITIATED : The network enters the state 5GMM-DEREGISTERED-INITIATED after it has started a de-registration procedure and is waiting for a response from the UE.<br />
<br />
=== 5.1.4 Coordination between 5GMM and EMM ===<br />
<br />
==== 5.1.4.1 General ====<br />
If both 5GMM and EMM are enabled, a UE, operating in single-registration mode, shall maintain one common registration for 5GMM for 3GPP access and EMM.<br />
<br />
Coordination between 5GMM for 3GPP access and EMM for a UE, which is capable of N1 mode and S1 mode and operates in dual-registration mode, is not needed, except as specified in subclause 4.8.3.<br />
<br />
The coordination between 5GMM for 3GPP access and EMM in subclauses 5.1.4.2 and 5.1.4.3 only applies to the UEs operating in single-registration mode.<br />
<br />
Regarding the coordination of "SIM/USIM considered invalid" and "USIM considered invalid for 5GS services" between the various mobility management entities see subclause 5.1.5.<br />
<br />
==== 5.1.4.2 Coordination between 5GMM for 3GPP access and EMM with N26 interface ====<br />
<br />
;N26 interface:N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking between EPC and the NG core.<br />
<br />
A UE that is not registered shall be in state EMM-DEREGISTERED and state 5GMM-DEREGISTERED for 3GPP access.<br />
<br />
In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter (see 3GPP TS 24.301).<br />
<br />
At inter-system change from S1 mode to N1 mode, the UE shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP accessand EMM-REGISTERED.NO-CELL-AVAILABLE and initiate a registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).<br />
<br />
In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE. The UE shall reset the registration attempt counter for 3GPP access and the attach attempt counter or tracking area updating attempt counter (see 3GPP TS 24.301).<br />
<br />
At inter-system change from N1 mode to S1 mode when there is no active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, and EMM-REGISTERED without PDN connection is not supported by the UE or the MME, the UE shall enter state 5GMM-DEREGISTERED for 3GPP access and state EMM-DEREGISTERED and then initiate the EPS attach procedure. If EMM-REGISTERED without PDN connection is supported by the UE and the MME, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure.<br />
<br />
At inter-system change from N1 mode to S1 mode when there is at least one active PDU session for which interworking with EPS is supported as specified in subclause 6.1.4.1, the UE shall enter substates EMM-REGISTERED.NORMAL-SERVICE and 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and initiate a tracking area updating procedure (see 3GPP TS 24.301).<br />
<br />
==== 5.1.4.3 Coordination between 5GMM for 3GPP access and EMM without N26 interface ====<br />
<br />
A UE operating in the single-registration mode that is not registered over 3GPP access shall be in state EMM-DEREGISTERED and in state 5GMM-DEREGISTERED for 3GPP access.<br />
<br />
In N1 mode, upon successful completion of a registration procedure over 3GPP access, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE as described in subclause 5.3.5.2 for 3GPP access and EMM-REGISTERED.NO-CELL-AVAILABLE.<br />
<br />
At inter-system change from N1 mode to S1 mode in 5GMM-IDLE mode, the UE shall behave as specified in subclause 4.8.2.3.<br />
<br />
In S1 mode, upon successful completion of an attach or tracking area updating procedure, the UE operating in the single-registration mode shall enter substates 5GMM-REGISTERED.NO-CELL-AVAILABLE for 3GPP access and EMM-REGISTERED.NORMAL-SERVICE.<br />
<br />
At inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, the UE operating in the single-registration mode shall enter substates EMM-REGISTERED.NO-CELL-AVAILABLE and 5GMM- REGISTERED.NORMAL-SERVICE for 3GPP access and then initiate the registration procedure for mobility and periodic registration update over 3GPP access indicating "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message (see subclause 5.5.1.3).<br />
<br />
=== 5.1.5 Coordination between 5GMM and GMM ===<br />
<br />
Coordination between 5GMM and GMM states is not required.<br />
<br />
Regardless whether the UE is operating in single-registration mode or dual-registration mode,<br />
* if the UE considers the SIM/USIM invalid for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the SIM/USIM invalid for all of them; and<br />
* if the UE considers the USIM invalid for 5GS services for any of: 3GPP access in N1 mode, S1 mode, A/Gb mode or Iu mode, then it considers the USIM invalid for 5GS services for all of them.<br />
<br />
== 5.3 General on elementary 5G Mobility Management (5GMM) procedures ==<br />
<br />
=== 5.3.1 5GMM modes and N1 NAS signalling connection ===<br />
<br />
==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====<br />
When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial Non-Access Stratum (NAS) message, the User Equipment (UE) shall request the lower layer to establish an Radio Resource Controller (RRC) connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access.<br />
<br />
When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access.<br />
<br />
Initial NAS messages are:<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST message;</li><br />
<li>DEREGISTRATION REQUEST message;</li><br />
<li>SERVICE REQUEST message; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST.</li><br />
</ol><br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.<br />
<br />
For the routing of the initial NAS message to the appropriate AMF, if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules...see spec<br />
<br />
== 5.2 Behaviour of the UE in state 5GMM-DEREGISTERED and state 5GMM-REGISTERED ==<br />
<br />
== 5.3 General on elementary 5GMM procedures ==<br />
<br />
=== 5.3.1 5GMM modes and N1 NAS signalling connection ===<br />
<br />
==== 5.3.1.1 Establishment of the N1 NAS signalling connection ====<br />
<br />
<span style="color:red">When the UE is in 5GMM-IDLE mode over 3GPP access and needs to transmit an initial NAS message, the UE shall request the lower layer to establish an RRC connection. Upon indication from the lower layers that the RRC connection has been established, the UE shall consider that the N1 NAS signalling connection over 3GPP access is established and enter 5GMM-CONNECTED mode over 3GPP access</span>.<br />
<br />
<span style="color:red">When the UE is in 5GMM-IDLE mode over non-3GPP access, and the UE receives an indication from the lower layers of non-3GPP access, that the access stratum connection is established between the UE and the network, the UE shall send an initial NAS message, consider the N1 NAS signalling connection is established and enter 5GMM-CONNECTED mode over non-3GPP access</span>.<br />
<br />
Initial NAS messages are:<br />
<ol type="a"><br />
<li>REGISTRATION REQUEST message;</li><br />
<li>DEREGISTRATION REQUEST message;</li><br />
<li>SERVICE REQUEST message; and</li><br />
<li>CONTROL PLANE SERVICE REQUEST.</li><br />
</ol><br />
<br />
If the UE is capable of both N1 mode and S1 mode and lower layers provide an indication that the current E-UTRA cell is connected to both EPC and 5GCN, for the routing of the REGISTRATION REQUEST message during the initial registration procedure to the appropriate core network (EPC or 5GCN), the UE NAS provides the lower layers with the selected core network type information.<br />
<br />
For the routing of the initial NAS message to the appropriate AMF, <span style="color:red">if the UE holds a 5G-GUTI or 4G-GUTI, the UE NAS provides the lower layers with the UE identity according to the following rules</span>:<br />
<ol type="a"><br />
<li>if the registration procedure for mobility and periodic update was triggered due to the last CONFIGURATION UPDATE COMMAND message containing the Configuration update indication IE with the Registration bit set to "registration requested" and including:<br />
# no other parameters;<br />
# one or both of the Allowed NSSAI IE and the Configured NSSAI IE; or<br />
# the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed";<br />
:the <span style="color:red">UE NAS shall not provide the lower layers with the 5G-S-TMSI or the registered GUAMI</span>;</li><br />
<li>if the service request procedure was initiated over non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the registered GUAMI, but shall not provide the lower layers with the 5G-S-TMSI</span>;</li><br />
<li>if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over untrusted non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI</span>;<br />
<br />
if the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over trusted non-3GPP access, <span style="color:red">the UE NAS shall provide the lower layers with the 5G-GUTI, if available, otherwise shall provide the lower layers with the SUCI</span>;<br />
<br />
if the UE is the 5G-RG and the initial NAS message other than the SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message was initiated over wireline access, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclause 5.5.1.2.2 and 5.5.1.3.2, if available, otherwise shall not provide the lower layers with any UE identity</span>;</li><br />
<li>if the UE does not hold a 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration procedure and if:<br />
# the UE operating in the single-registration mode performs a registration procedure for mobility and periodic update indicating "mobility registration updating" following an inter-system change from S1 mode to N1 mode; or<br />
# the UE which was previously registered in S1 mode before entering state EMM-DEREGISTERED, performs an initial registration procedure, the UE has received the interworking without N26 interface indicator set to "interworking without N26 interface not supported" from the network, and the UE holds a 4G-GUTI;<br />
<br />
then <span style="color:red">the UE NAS provides the lower layers with a GUAMI part of the 5G-GUTI mapped from 4G-GUTI as specified in 3GPP TS 23.003 with an indication that the GUAMI is mapped from EPS</span>; or</li><br />
<li>otherwise:<br />
# if the tracking area of the current cell is in the registration area, <span style="color:red">the UE NAS shall provide the lower layers with the 5G-S-TMSI, but shall not provide the registered GUAMI to the lower layers</span>; or<br />
# if the tracking area of the current cell is not in the registration area, <span style="color:red">the UE NAS shall provide the lower layers with the GUAMI of the 5G-GUTI that the UE NAS has selected as specified in the subclauses 5.5.1.2.2 and 5.5.1.3.2, but shall not provide the lower layers with the 5G-S-TMSI</span>.</li><br />
</ol><br />
<br />
<br />
For 3GPP access and untrusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, <span style="color:red">the UE NAS does not provide the lower layers with the 5G-S-TMSI or the registered GUAMI</span>. For trusted non-3GPP access, if the UE does not hold a 5G-GUTI and the UE does not hold a 4G-GUTI, <span style="color:red">the UE NAS provides the lower layers with the SUCI</span>.<br />
<br />
The UE NAS also provides the lower layers with the identity of the selected PLMN (see 3GPP TS 38.331) if the UE is not operating in SNPN access operation mode. If the UE is operating in SNPN access operation mode, the UE NAS provides the lower layers with the SNPN identity of the selected SNPN. In a shared network, the UE shall choose one of the PLMN identity(ies) or SNPN identity(ies) as specified in 3GPP TS 23.122.<br />
<br />
The UE NAS layer may provide the lower layers with an NSSAI as specified in subclause 4.6.2.3.<br />
<br />
If the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the UE NAS layer shall provide the lower layers with an indication that the connection is for onboarding.<br />
<br />
==== 5.3.1.2 Re-establishment of the N1 NAS signalling connection ====<br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li><span style="color:red">initiate the registration procedure for mobility and periodic registration update</span> and include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.5.1.3 for further details).</li><br />
</ol><br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has pending uplink user data for PDU session(s) with user-plane resources already established but no pending NAS procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication (see subclause 5.6.1 for further details).</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending registration procedure, a service request procedure, or a de-registration procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode;</li><br />
<li>proceed with the pending procedure; and</li><br />
<li>if the pending procedure is a service request or <span style="color:red">registration procedure</span> and the SERVICE REQUEST message, the CONTROL PLANE SERVICE REQUEST message or the REGISTRATION REQUEST message does not include UE request type IE with Request type value set to "NAS signalling connection release", the UE shall include the Uplink data status IE in the SERVICE REQUEST message, or <span style="color:red">in the REGISTRATION REQUEST message</span>, indicating the PDU session(s) for which user-plane resources were not active prior to receiving a fallback indication from the lower layers and the UE has pending user data to be sent over 3GPP access, if any, and the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclauses 5.5.1.3 and 5.6.1 for further details).</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has a pending NAS procedure other than a registration procedure, a service request procedure, or a de-registration procedure, the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode;</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details); and</li><br />
<li>upon successful service request procedure completion, proceed with any pending procedure.</li><br />
</ol><br />
<br />
When the UE in 5GMM-CONNECTED mode over 3GPP access receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, and the UE was using network resources for ProSe direct discovery over PC5 or ProSe direct communication over PC5 (see 3GPP TS 23.304), the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li>initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details).</li><br />
</ol><br />
The cases above apply when the UE is in an allowed area or when the UE is not in a non-allowed area.<br />
<br />
When the UE:<br />
<ol type="a"><br />
<li>is in a non-allowed area or is not in an allowed area;</li><br />
<li>is in 5GMM-CONNECTED mode over 3GPP access;</li><br />
<li>receives a fallback indication from lower layers; and</li><br />
<li>does not have signalling pending,</li><br />
</ol><br />
the UE shall:<br />
<ol type="a"><br />
<li>enter 5GMM-IDLE mode; and</li><br />
<li><span style="color:red">initiate the registration procedure for mobility and periodic registration update</span>. The UE shall not include the Uplink data status IE in the REGISTRATION REQUEST message except if the PDU session for which user-plane resources were active is an emergency PDU session, or if the UE is configured for high priority access in the selected PLMN.</li><br />
</ol><br />
<br />
In the above cases when the UE receives a fallback indication from lower layers, if the UE is in non-allowed area or not in allowed area, the UE shall behave as specified in subclause 5.3.5.<br />
<br />
==== 5.3.1.3 Release of the N1 NAS signalling connection ====<br />
<br />
See spec for details...<br />
<br />
==== 5.3.1.4 5GMM-CONNECTED mode with RRC inactive indication ====<br />
<br />
See spec for details...<br />
<br />
==== 5.3.1.5 Suspend and resume of the N1 NAS signalling connection ====<br />
<br />
See spec for details...<br />
<br />
=== 5.3.2 Permanent identifiers ===<br />
A globally unique permanent identity, the 5G subscription permanent identifier (SUPI), is allocated to each subscriber for 5GS-based services. The IMSI, the network specific identifier, the GCI and the GLI are valid SUPI types. When the SUPI contains a network specific identifier, a GCI or a GLI, it shall take the form of a network access identifier (NAI). When the UE performs initial registration for onboarding services in SNPN or is registered for onboarding services in SNPN, the SUPI contains the onboarding SUPI derived from the default UE credentials for primary authentication. The UE derives the onboarding SUPI before or during the initial registration for onboarding services in SNPN and uses the derived onboarding SUPI in the initial registration for onboarding services in SNPN and while registered for onboarding services in SNPN.<br />
<br />
The structure of the SUPI and its derivatives are specified in 3GPP TS 23.003. See [[My 3GPP TS 23.003 notes]]<br />
<br />
The UE provides the SUPI to the network in concealed form. The SUCI is a privacy preserving identifier containing the concealed SUPI. When the SUPI contains a network specific identifier, a GCI or a GLI, the SUCI shall take the form of a NAI as specified in 3GPP TS 23.003.<br />
<br />
<span style="color:red">A UE supporting N1 mode includes a SUCI:</span><br />
<ol type="a"><br />
<li>in the REGISTRATION REQUEST message when the UE is attempting initial registration procedure <span style="color:red">and a valid 5G-GUTI is not available</span>;</li><br />
<li>in the IDENTITY RESPONSE message, <span style="color:red">if the SUCI is requested by the network during the identification procedure</span>; and</li><br />
<li>in the DEREGISTRATION REQUEST message when the UE initiates a de-registration procedure <span style="color:red">and a valid 5G-GUTI is not available</span>.</li><br />
</ol><br />
<span style="color:red">If the UE uses the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI, the SUCI contains the unconcealed SUPI.</span><br />
<br />
When:<br />
* not operating in SNPN access operation mode; or<br />
* operating in SNPN access operation mode but not performing initial registration for onboarding services and not registered for onboarding services;<br />
<br />
the UE shall use the "null-scheme" if:<br />
<ol type="a"><br />
<li>the home network has not provisioned the public key needed to generate a SUCI;</li><br />
<li>the home network has configured "null-scheme" to be used for the UE;</li><br />
<li>the UE needs to perform a registration procedure for emergency services after the failure of authentication procedure or after reception of a REGISTRATION REJECT message with the 5GMM cause #3 "Illegal UE", or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully, and the UE does not have a valid 5G-GUTI for the selected PLMN; or</li><br />
<li>the UE receives an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully.</li><br />
</ol><br />
<br />
When operating in SNPN access operation mode and:<br />
* performing initial registration for onboarding services; or<br />
* registered for onboarding services;<br />
<br />
the UE shall use the "null-scheme" if:<br />
<ol type="a"><br />
<li>the public key needed to generate a SUCI is not configured as part of the default UE credentials for primary authentication; or</li><br />
<li>"null-scheme" usage is configured as part of the default UE credentials.</li><br />
</ol><br />
<br />
If:<br />
<ol type="a"><br />
<li>the UE uses the "null-scheme" as specified in 3GPP TS 33.501 [24] to generate a SUCI;</li><br />
<li>the UE operates in SNPN access operation mode and:<br />
# an indication to use anonymous SUCI which is associated with the selected entry of the "list of subscriber data", is configured in the ME, if the UE is not registering or registered for onboarding services in SNPN; or<br />
# an indication to use anonymous SUCI which is associated with the default UE credentials, is configured in the ME, if the UE is registering or registered for onboarding services in SNPN;</li><br />
NOTE 1: The ME can be configured with an indication to use anonymous SUCI associated with an entry of "list of subscriber data" when the EAP method associated with the credentials of the entry supports SUPI privacy at the EAP layer, or can be configured with an indication to use anonymous SUCI associated with the default UE credentials when the EAP method associated with the default UE credentials supports SUPI privacy at the EAP layer, or both.<br />
</br></br><br />
Editor's note: (WI eNPN, CR 4139) it is FFS whether another UE-level configuration for usage of anonymous SUCI is needed.<br />
<br />
<li>the UE does not need to perform a registration procedure for emergency services, or to initiate a de-registration procedure before the registration procedure for emergency services was completed successfully; and</li><br />
<li>the UE does not receive an identity request for SUCI during a registration procedure for emergency services or during a de-registration procedure that was initiated before the registration procedure for emergency services was completed successfully;</li><br />
</ol><br />
then the UE shall use anonymous SUCI as specified in 3GPP TS 23.003.<br />
<br />
A W-AGF acting on behalf of an FN-RG shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.<br />
<br />
A W-AGF acting on behalf of an N5GC device shall use the "null-scheme" as specified in 3GPP TS 33.501 to generate a SUCI.<br />
<br />
If a UE is a MUSIM UE, the UE shall use a separate permanent equipment identifier (PEI) for each USIM, if any, and each entry of "list of subscriber data", if any, the UE operates for accessing 5GS-based services; otherwise, a UE contains and uses a permanent equipment identifier (PEI) for accessing 5GS-based services. When the UE is registered with a network by using a PEI, the UE shall not use that PEI to register with another network until the UE is de-registered from the network.<br />
<br />
In this release of the specification, the IMEI, the IMEISV, the MAC address together with the MAC address usage restriction indication and the EUI-64 are the only PEI formats supported by 5GS. The structure of the PEI and its formats are specified in 3GPP TS 23.003.<br />
<br />
Each UE supporting at least one 3GPP access technology (i.e. satellite NG-RAN, NG-RAN, E-UTRAN, UTRAN or GERAN) contains a PEI in the IMEI format and shall be able to provide an IMEI and an IMEISV upon request from the network.<br />
<br />
Each UE not supporting any 3GPP access technologies and supporting NAS over untrusted or trusted non-3GPP access shall have a PEI in the form of the Extended Unique Identifier EUI-64 of the access technology the UE uses to connect to the 5GC.<br />
<br />
A UE supporting N1 mode includes a PEI:<br />
<ol type="a"><br />
<li>when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";</li><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTITY RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
<br />
Each 5G-RG supporting only wireline access and each FN-RG shall have a permanent MAC address configured by the manufacturer. For 5G-CRG, the permanent MAC address configured by the manufacturer shall be a cable modem MAC address.<br />
<br />
When the 5G-RG contains neither an IMEI nor an IMEISV, the 5G-RG shall use as a PEI the 5G-RG's permanent MAC address configured by the manufacturer and the MAC address usage restriction indication set to "no restrictions".<br />
<br />
The Wireless Access Gateway Function (W-AGF) acting on behalf of the Fixed Network Residential Gateway (FN-RG) shall use as a PEI the MAC address provided by the FN-RG and if the MAC address provided by the FN-RG is not unique or does not correspond to the FN-RG's permanent MAC address according to W-AGF's configuration, the MAC address usage restriction indication set to "MAC address is not usable as an equipment identifier" otherwise the MAC address usage restriction indication set to "no restrictions".<br />
<br />
The 5G-RG containing neither an IMEI nor an IMEISV shall include the PEI containing the MAC address together with the MAC address usage restriction indication:<br />
<ol type="a"><br />
<li>when neither SUPI nor valid 5G-GUTI is available to use for emergency services in the REGISTRATION REQUEST message with 5GS registration type IE set to "emergency registration";</li><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
:NOTE 2: In case c) above, the MAC address is provided even though AMF requests the IMEISV.<br />
<br />
The W-AGF acting on behalf of the FN-RG shall include the PEI containing the MAC address together with the MAC address usage restriction indication:<br />
<ol type="a"><br />
<li>when the network requests the PEI by using the identification procedure, in the IDENTIFICATION RESPONSE message; and</li><br />
<li>when the network requests the IMEISV by using the security mode control procedure, in the SECURITY MODE COMPLETE message.</li><br />
</ol><br />
:NOTE 3: In case b) above, the MAC address is provided even though AMF requests the IMEISV.<br />
<br />
The W-AGF acting on behalf of the N5GC device shall use as a PEI the MAC address provided by the N5GC device and the MAC address usage restriction indication set to "no restrictions". Based on operator policy, the W-AGF acting on behalf of the N5GC device may encode the MAC address of the N5GC device using the EUI-64 format as specified in IEEE "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" and use as a PEI the derived EUI-64.<br />
:NOTE 4: The MAC address of an N5GC device is universally/globally unique.<br />
<br />
The AMF can request the PEI at any time by using the identification procedure.<br />
<br />
=== 5.3.3 Temporary identities ===<br />
<br />
<span style="color:red">A temporary user identity for 5GS-based services, the 5G globally unique temporary identity (5G-GUTI), is used for identification within the signalling procedures. In case of PLMN the 5G-GUTI is globally unique and in case of Standalone Non-Public Network (SNPN) the 5G-GUTI is unique within an SNPN. When the UE is registered to the same PLMN or SNPN over 3GPP and non-3GPP access, the UE and the AMF maintain one 5G-GUTI that is common to both 3GPP and non-3GPP access. When the UE is required to delete the 5G-GUTI according to a NAS procedure, the UE shall delete the 5G-GUTI only if it is not registered to the same PLMN or SNPN through other access. When the UE is registered to different PLMNs or SNPNs over 3GPP access and non-3GPP access, the UE maintains two 5G-GUTIs, a 5G-GUTI for the registration with a PLMN or SNPN over the 3GPP access and another 5G-GUTI for the registration with another PLMN or SNPN over the non-3GPP access. In the paging and service request procedures, a shortened form of the 5G-GUTI, the 5G S-temporary mobile subscriber identity (5G-S-TMSI), is used to enable more efficient radio signalling. The purpose of the 5G-GUTI and 5G-S-TMSI is to provide identity confidentiality, i.e., to protect a user from being identified and located by an intruder.</span> The structure of the 5G-GUTI and its derivatives are specified in 3GPP TS 23.003. The 5G-GUTI has two main components (see 3GPP TS 23.501):<br />
<ol type="a"><li>the GUAMI; and</li><br />
<li>the 5G-TMSI that provides an unambiguous identity of the UE within the AMF(s) identified by the GUAMI.</li><br />
</ol><br />
:NOTE: The UE registered with an SNPN over non-3GPP access refers to the UE accessing SNPN services via a PLMN.<br />
<br />
The 5G-S-TMSI has three main components:<br />
<ol type="a"><br />
<li>the AMF set ID that uniquely identifies the AMF set within the AMF region;</li><br />
<li>the AMF pointer that identifies one or more AMFs within the AMF set; and</li><br />
<li>the 5G-TMSI.</li><br />
</ol><br />
<br />
A UE supporting N1 mode includes a valid 5G-GUTI, if any is available, in the REGISTRATION REQUEST and DEREGISTRATION REQUEST messages. In the SERVICE REQUEST message, the UE includes a valid 5G-S-TMSI as user identity. <span style="color:red">The AMF shall assign a new 5G-GUTI for a particular UE</span>:<br />
<ol type="a"><br />
<li><span style="color:green">during a successful initial registration procedure</span>;</li><br />
<li><span style="color:green">during a successful registration procedure for mobility registration update</span>;</li><br />
<li><span style="color:green">after a successful service request procedure invoked as a response to a paging request from the network and before</span> the:<br />
# release of the N1 NAS signalling connection; or<br />
# suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;<br />
:as specified in subclause 5.4.4.1; and</li><br />
<li><span style="color:green">after the AMF receives an indication from the lower layers that it has received the NGAP UE context resume request message as specified in 3GPP TS 38.413 for a UE in 5GMM-IDLE mode with suspend indication and this resumption is a response to a paging request from the network, and before</span> the:<br />
# release of the N1 NAS signalling connection; or<br />
# suspension of the N1 NAS signalling connection due to user plane CIoT 5GS optimization i.e. before the UE and the AMF enter 5GMM-IDLE mode with suspend indication;<br />
:as specified in subclause 5.4.4.1.</li><br />
</ol><br />
<br />
<span style="color:red">The AMF should assign a new 5G-GUTI for a particular UE during a successful registration procedure for periodic registration update.</span> <span style="color:red">The AMF may assign a new 5G-GUTI at any time for a particular UE by performing the generic UE configuration update procedure.</span><br />
<br />
If a new 5G-GUTI is assigned by the AMF, the UE and the AMF handle the 5G-GUTI as follows:<br />
<ol type="a"><li>Upon receipt of a 5GMM message containing a new 5G-GUTI, the UE considers the new 5G-GUTI as valid and the old 5G-GUTI as invalid, stops timer T3519 if running, and deletes any stored SUCI. The new 5G-GUTI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.</li><br />
<li>The AMF considers the old 5G-GUTI as invalid as soon as an acknowledgement for a registration or generic UE configuration update procedure is received.</li><br />
</ol><br />
<br />
=== 5.3.4 Registration areas ===<br />
<br />
Within the 5GS, <span style="color:red">the registration area is managed independently per access type, i.e., 3GPP access or non-3GPP access. The AMF assigns a registration area to the UE during the registration procedure</span>. A registration area is defined as a set of tracking areas and each of these tracking areas consists of one or more cells that cover a geographical area. Within the 5GS, the concept of "registration to multiple tracking areas" applies:<br />
<ol type="a"><br />
<li>A tracking area is identified by a TAI which is broadcast in the cells of the tracking area. The TAI is constructed from a TAC and a PLMN identity. In case of a shared network:<br />
<ol type="1"><li>one or more TACs; and</li><br />
<li>any of the following:<br />
<ol type="i"><br />
<li>multiple PLMN identities;</li><br />
<li>multiple SNPN identities; or</li><br />
<li>one or more PLMN identities and one or more SNPN identities;<br />
are broadcast.</li></ol><br />
</li></ol><br />
<li>In order to reduce the tracking area update signalling within the 5GS, the AMF can assign several tracking areas to the UE. These tracking areas construct a list of tracking areas which is identified by a TAI list. When generating the TAI list, the AMF shall include only TAIs that are applicable on the access where the TAI list is sent. The AMF shall be able to allocate a TAI list over different NG-RAN access technologies. The AMF shall not allocate a TAI list containing both tracking areas in NB-N1 mode and tracking areas not in NB-N1 mode.</li><br />
<li>The UE considers itself registered to a list of tracking areas and does not need to trigger the registration procedure for mobility and periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) as long as the UE stays in one of the tracking areas of the list of tracking areas received from the AMF.</li><br />
<li>The UE will consider the TAI list as valid, until it receives a new TAI list in the next registration procedure for mobility and periodic registration update or generic UE configuration update procedure, or the UE is commanded by the network to delete the TAI list by a reject message or it is deregistered from the 5GS. If the registration request is accepted or the TAI list is reallocated by the AMF, the AMF shall provide at least one entry in the TAI list. If the new and the old TAI list are identical, the AMF does not need to provide the new TAI list to the UE during mobility registration update or periodic registration update.</li><br />
<li>The TAI list can be reallocated by the AMF.</li><br />
<li>When the UE is deregistered from the 5GS, the TAI list in the UE is invalid.</li><br />
<li>The UE includes the last visited registered TAI, if available, to the AMF. The last visited registered TAI is stored in a non-volatile memory in the USIM if the corresponding file is present in the USIM, else in the non-volatile memory in the ME, as described in annex C.</li><br />
</ol><br />
<br />
=== 5.3.5 Service area restrictions ===<br />
<br />
==== 5.3.5.1 General ====<br />
<br />
Service area restrictions are applicable only to 3GPP access and to wireline access.<br />
<br />
Subclause 5.3.5.2 applies when the UE accesses 5GCN over 3GPP access.<br />
<br />
Subclause 5.3.5.3 applies when the 5G-RG or the W-AGF acting on behalf of an FN-CRG (or on behalf of the N5GC device) access 5GCN over wireline access.<br />
:NOTE: Service area restrictions are not applicable for the W-AGF acting on behalf of the FN-BRG.<br />
<br />
==== 5.3.5.2 3GPP access service area restrictions ====<br />
<br />
<span style="color:blue">The service area restrictions consist of tracking areas forming either an allowed area, or a non-allowed area</span>. The tracking areas belong to either the registered PLMN or its equivalent PLMNs in the registration area. The allowed area can contain up to 16 tracking areas or include all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area. The non-allowed area can contain up to 16 tracking areas. The network conveys the service area restrictions to the UE by including either an allowed area, or a non-allowed area, but <span style="color:red">not both</span>, in the Service area list IE of a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message.<br />
<br />
If the network does not convey the service area restrictions to the UE in the Service area list IE of a REGISTRATION ACCEPT message, the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) in the registration area as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".<br />
<br />
When the UE receives a Service area list IE with an allowed area indication during a registration procedure or a generic UE configuration update procedure:<br />
<ol type="a"><br />
<li>if the "Type of list" included in the Service area list IE does not indicate "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall delete the old list of "allowed tracking areas" and store the tracking areas in the allowed area as the list of "allowed tracking areas". If the UE has a stored list of "non-allowed tracking areas", the UE shall delete that list; or</li><br />
<li>if the "Type of list" included in the Service area list IE indicates "all TAIs belonging to the PLMNs in the registration area are allowed area", the UE shall treat all tracking areas in the registered PLMN and its equivalent PLMN(s) as allowed area and delete the stored list of "allowed tracking areas" or the stored list of "non-allowed tracking areas".</li><br />
</ol><br />
<br />
When the UE receives a Service area list IE with a non-allowed area indication during a registration procedure or a generic UE configuration update procedure, the UE shall delete the old list of "non-allowed tracking areas" and store the tracking areas in the non-allowed area as the list of "non-allowed tracking areas". If the UE has a stored list of "allowed tracking areas", the UE shall delete that list.<br />
<br />
If the UE is successfully registered to a PLMN and has a stored list of "allowed tracking areas":<br />
<br />
See spec for details...<br />
<br />
=== 5.3.6 Mobile initiated connection only (MICO) mode ===<br />
<br />
=== 5.3.7 Handling of the periodic registration update timer and mobile reachable timer ===<br />
<br />
The periodic registration update procedure is used over 3GPP access to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic registration update timer, T3512.<br />
<br />
If the UE is registered over the 3GPP access, the AMF maintains an implicit de-registration timer to control when the UE is considered implicitly de-registered over the 3GPP access. If the UE is registered over the non-3GPP access, the AMF also maintains a non-3GPP implicit de-registration timer to control when the UE is considered implicitly de-registered over the non-3GPP access. The UE registered over the non-3GPP access maintains a non-3GPP de-registration timer to control when the UE is considered implicitly de-registered for the non-3GPP access.<br />
<br />
The AMF shall start a non-3GPP implicit de-registration timer for the UE registered over non-3GPP access when the N1 NAS signalling connection over non-3GPP access is released.<br />
<br />
The UE registered over non-3GPP access shall reset and start a non-3GPP de-registration timer when the N1 NAS signalling connection over non-3GPP access is released. The non-3GPP de-registration timer is stopped when the UE enters 5GMM-CONNECTED mode over non-3GPP access or the 5GMM-DEREGISTERED state over non-3GPP access.<br />
<br />
The non-3GPP implicit de-registration timer shall be longer than the non-3GPP de-registration timer.<br />
<br />
The value of timer T3512 is sent by the network to the UE in the REGISTRATION ACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE until a new value is received. The periodic registration update timer only applies to the UE registered to the 5GS services over 3GPP access.<br />
<br />
If timer T3512 received by the UE in a REGISTRATION ACCEPT message contains an indication that the timer is deactivated or the timer value is zero, then timer T3512 is deactivated and the UE shall not perform the periodic registration update procedure.<br />
:NOTE 1: The UE does not perform the periodic registration update procedure for non-3GPP access.<br />
<br />
If during the registration procedure, the AMF does not indicate "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is reset and started with its initial value, when the UE changes from 5GMM-CONNECTED over 3GPP access to 5GMM-IDLE mode over 3GPP access. Timer T3512 is stopped when the UE enters 5GMM-CONNECTED mode over 3GPP access or the 5GMM-DEREGISTERED state over 3GPP access.<br />
<br />
If during the registration procedure, the AMF indicates "strictly periodic registration timer supported" in the MICO indication IE to the UE, timer T3512 is started with its initial value after the completion of the registration procedure. The UE shall neither stop nor reset the timer T3512 when the UE enters 5GMM-CONNECTED or when changing from 5GMM-CONNECTED mode to 5GMM-IDLE mode. If the timer T3512 expires,<br />
<ol type="a"><br />
<li>the UE in 5GMM-CONNECTED mode over 3GPP access shall reset and start the timer T3512 with its initial value; or</li><br />
<li>the UE in 5GMM-IDLE mode over 3GPP access shall perform the periodic registration procedure.</li><br />
</ol><br />
<br />
If the UE is registered for emergency services, and timer T3512 expires, the UE shall not initiate a periodic registration update procedure, but shall locally de-register from the network. When the UE is camping on a suitable cell, it may re-register to regain normal service.<br />
<br />
When a UE is not registered for emergency services, and timer T3512 expires when the UE is in 5GMM-IDLE mode, the periodic registration update procedure shall be started.<br />
<br />
If the UE is not registered for emergency services, and is in a state other than 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access when timer T3512 expires, the periodic registration update procedure is delayed until the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE over 3GPP access.<br />
:NOTE 2: When the UE returns to 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE and it needs to initiate other 5GMM procedure than the periodic registration update procedure then, based on UE implementation, the 5GMM procedure can take precedence.<br />
<br />
The network supervises the periodic registration update procedure of the UE by means of the mobile reachable timer.<br />
<br />
If the UE is not registered for emergency services, the mobile reachable timer shall be longer than the value of timer T3512. In this case, by default, the mobile reachable timer is 4 minutes greater than the value of timer T3512.<br />
<br />
The network behaviour upon expiry of the mobile reachable timer is network dependent, but typically the network stops sending paging messages to the UE on the first expiry, and may take other appropriate actions.<br />
<br />
If the UE is registered for emergency services, the AMF shall set the mobile reachable timer with a value equal to timer T3512. When the mobile reachable timer expires, the AMF shall locally de-register the UE.<br />
<br />
The mobile reachable timer shall be reset and started with the value as indicated above, when the AMF releases the NAS signalling connection for the UE. The mobile reachable timer shall be stopped when a NAS signalling connection is established for the UE.<br />
<br />
Upon expiry of the mobile reachable timer the network shall start the implicit de-registration timer over 3GPP access. The value of the implicit de-registration timer over 3GPP access is network dependent. If MICO mode is activated, the network shall start the implicit de-registration timer over 3GPP access when the UE enters 5GMM-IDLE mode at the AMF over 3GPP access. The default value of the implicit de-registration timer over 3GPP access is 4 minutes greater than the value of timer T3512.<br />
<br />
If the implicit de-registration timer expires before the UE contacts the network, the network shall implicitly de-register the UE. The implicit de-registration timer shall be stopped when a NAS signalling connection is established for the UE.<br />
<br />
If the non-3GPP implicit de-registration timer expires before the UE contacts the network over the non-3GPP access, the network shall implicitly de-register the UE and enter the state 5GMM-DEREGISTERED over non-3GPP access for the UE. The non-3GPP implicit de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.<br />
<br />
If the non-3GPP de-registration timer expires before the UE contacts the network over the non-3GPP access, the UE shall enter the state 5GMM-DEREGISTERED over non-3GPP access. The non-3GPP de-registration timer shall be stopped when a NAS signalling connection over non-3GPP access is established for the UE.<br />
<br />
If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "Non-3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of timer T3512, the AMF sets the mobile reachable timer and the implicit de-registration timer such that the sum of the timer values is greater than the value of timer T3346.<br />
<br />
If the AMF provides T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the AMF sets the non-3GPP implicit de-registration timer value to be 8 minutes greater than the value of timer T3346.<br />
<br />
If the UE receives T3346 value IE in the DEREGISTRATION REQUEST message with Access type set to "3GPP access" in Deregistration type IE, REGISTRATION REJECT message during a registration procedure for mobility and periodic registration update or SERVICE REJECT message and the value of timer T3346 is greater than the value of the non-3GPP de-registration timer, the UE sets the non-3GPP de-registration timer value to be 4 minutes greater than the value of timer T3346.<br />
<br />
=== 5.3.9 Handling of NAS level mobility management congestion control ===<br />
<br />
== 5.4 5GMM common procedures ==<br />
<br />
=== 5.4.2 Security mode control (SMC) procedure ===<br />
<br />
==== 5.4.2.1 General ====<br />
<br />
The purpose of the NAS security mode control procedure is to take a 5G NAS security context into use, and initialise and start NAS signalling security between the UE and the AMF with the corresponding 5G NAS keys and 5G NAS security algorithms.<br />
<br />
See spec for details...<br />
<br />
=== 5.4.3 Identification procedure ===<br />
<br />
==== 5.4.3.1 General ====<br />
<br />
The purpose of this procedure is to request a particular UE to provide specific identification parameters, e.g. the SUCI, the IMEI, the IMEISV, the EUI-64 or the MAC address. The SUCI is a privacy preserving identifier containing the concealed SUPI and the IMEI, the IMEISV, the EUI-64 and the MAC address are formats of PEI.<br />
<br />
See spec for details...<br />
<br />
== 5.5 5GMM specific procedures ==<br />
<br />
=== 5.5.1 Registration procedure ===<br />
<br />
==== 5.5.1.1 General ====<br />
<br />
The registration procedure is always initiated by the UE and used for initial registration as specified in subclause 5.5.1.2.2 or mobility and periodic registration update as specified in subclause 5.5.1.3.2.<br />
<br />
When the UE needs to initiate registration over both 3GPP access and non-3GPP access in the same PLMN (e.g. the 3GPP access and the selected N3IWF are located in the same PLMN), the UE:<br />
<ol type="a"><br />
<li>in 5GMM-REGISTERED-INITIATED over 3GPP access shall not initiate registration over non-3GPP access; or</li><br />
<li>in 5GMM-REGISTERED-INITIATED over non-3GPP access shall not initiate registration over 3GPP access.</li><br />
:NOTE 1: To which access (i.e. 3GPP access or non-3GPP access) the UE initiates registration first is up to UE implementation.<br />
</ol><br />
<br />
When the UE is registered with a PLMN over a non-3GPP access, the AMF and the UE maintain:<br />
<ol type="a"><br />
<li>registration state and state machine over non-3GPP access;</li><br />
<li>5G NAS security context;</li><br />
<li>5G-GUTI;</li><br />
<li>registration area for non-3GPP access, which is associated with a single TAI; and</li><br />
<li>non-3GPP de-registration timer in the UE and non-3GPP implicit de-registration timer in the AMF.</li><br />
</ol><br />
<br />
A registration attempt counter is used to limit the number of subsequently rejected registration attempts. The registration attempt counter shall be incremented as specified in subclause 5.5.1.2.7 or subclause 5.5.1.3.7. Depending on the value of the registration attempt counter, specific actions shall be performed. The registration attempt counter shall be reset when:<br />
* the UE is powered on;<br />
* a USIM is inserted;<br />
* a registration procedure is successfully completed;<br />
* an EPS attach or combined EPS attach procedure is successfully completed in S1 mode and the UE is operating in single-registration mode. In this case, the UE shall reset the registration attempt counter for 3GPP access;<br />
:NOTE 2: The registration attempt counter for non-3GPP access is not impacted by the EPS attach and the combined EPS attach procedure.<br />
* a registration procedure is rejected with cause #11, #12, #13, #15, #27, #31, #62, #72, #73, #74, #75, #76, #77 or #78;<br />
* a registration procedure is rejected with cause #3, #6 or #7, the REGISTRATION REJECT message is received without integrity protection and the counter for "SIM/USIM considered invalid for GPRS services" events has a value less than a UE implementation-specific maximum value.<br />
* a network initiated deregistration procedure is completed with cause #11, #12, #13, #15, #27; #62, #72, #74, #75, #76, #77 or #78; or<br />
* a new PLMN or SNPN is selected.<br />
<br />
Additionally, the registration attempt counter shall be reset when the UE is in substate 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION or 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE, and:<br />
* the current TAI is changed;<br />
* timer T3502 expires; or<br />
* timer T3346 is started.<br />
When the registration attempt counter is reset, the UE shall stop timer T3519 if running, and delete any stored SUCI.<br />
<br />
The lower layers indicate to NAS whether the network supports emergency services for the UE in limited service state (see 3GPP TS 38.331). This information is taken into account when deciding whether to initiate an initial registration for emergency services.<br />
<br />
==== 5.5.1.2 Registration procedure for initial registration ====<br />
<br />
===== 5.5.1.2.1 General =====<br />
<br />
This procedure can be used by a UE for initial registration for 5GS services.<br />
<br />
When the UE initiates the registration procedure for initial registration, the UE shall indicate "initial registration" in the 5GS registration type IE. When the UE initiates the registration procedure for emergency services, the UE shall indicate "emergency registration" in the 5GS registration type IE. When the UE initiates the initial registration for onboarding services in SNPN, the UE shall indicate "SNPN onboarding registration" in the 5GS registration type IE. When the UE initiates the initial registration procedure for disaster roaming services, the UE shall indicate "disaster roaming initial registration" in the 5GS registration type IE.<br />
<br />
If the MUSIM UE initiates the registration procedure for initial registration and indicates "emergency registration" in the 5GS registration type IE in the REGISTRATION REQUEST message, the network shall not indicate the support of:<br />
* the N1 NAS signalling connection release;<br />
* the paging indication for voice services;<br />
* the reject paging request; or<br />
* the paging restriction;<br />
in the REGISTRATION ACCEPT message.<br />
<br />
===== 5.5.1.2.2 Initial registration initiation =====<br />
The UE in state 5GMM-DEREGISTERED shall initiate the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF,<br />
<ol type="a"><br />
<li>when the UE performs initial registration for 5GS services;</li><br />
<li>when the UE performs initial registration for emergency services;</li><br />
<li>when the UE performs initial registration for SMS over NAS;</li><br />
<li>when the UE moves from GERAN to NG-RAN coverage or the UE moves from a UTRAN to NG-RAN coverage and the following applies:<br />
# the UE initiated a GPRS attach or routing area updating procedure while in A/Gb mode or Iu mode; or<br />
# the UE has performed 5G-SRVCC from NG-RAN to UTRAN as specified in 3GPP TS 23.216,<br />
:and since then the UE did not perform a successful EPS attach or tracking area updating procedure in S1 mode or registration procedure in N1 mode;<br />
<li>when the UE performs initial registration for onboarding services in SNPN; and</li><br />
<li>when the UE performs initial registration for disaster roaming services;</li><br />
</ol><br />
with the following clarifications to initial registration for emergency services:<br />
<ol type="a"><br />
<li>the UE shall not initiate an initial registration for emergency services over the current access, if the UE is already registered for emergency services over the non-current access, unless the initial registration has to be initiated to perform handover of an existing emergency PDU session from the non-current access to the current access; and</li><br />
NOTE 1: Transfer of an existing emergency PDU session between 3GPP access and non-3GPP access is needed e.g. if the UE determines that the current access is no longer available.<br />
<li>the UE can only initiate an initial registration for emergency services over non-3GPP access if it cannot register for emergency services over 3GPP access.</li><br />
</ol><br />
<br />
The UE initiates the registration procedure for initial registration by sending a REGISTRATION REQUEST message to the AMF, starting timer T3510. If timer T3502 is currently running, the UE shall stop timer T3502. If timer T3511 is currently running, the UE shall stop timer T3511.<br />
<br />
<span style="color:red">During initial registration the UE handles the 5GS mobile identity IE in the following order:</span><br />
<ol type="a"><br />
<li>if:<br />
<ol type="1"><br />
<li>the UE:</li><br />
<ol type="i"><br />
<li>was previously registered in S1 mode before entering state EMM-DEREGISTERED; and</li><br />
<li>has received an "interworking without N26 interface not supported" indication from the network; and</li><br />
</ol><br />
<li>EPS security context and a valid native 4G-GUTI are available;</li><br />
</ol><br />
<br />
then the UE shall create a 5G-GUTI mapped from the valid native 4G-GUTI as specified in 3GPP TS 23.003 and indicate the mapped 5G-GUTI in the 5GS mobile identity IE. The UE shall include the UE status IE with the EMM registration status set to "UE is not in EMM-REGISTERED state" and shall include an ATTACH REQUEST message as specified in 3GPP TS 24.301 in the EPS NAS message container IE.<br />
<br />
Additionally, if the UE holds a valid 5G GUTI, the UE shall include the 5G-GUTI in the Additional GUTI IE in the REGISTRATION REQUEST message in the following order:<br />
# a valid 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration, if available;<br />
# a valid 5G-GUTI that was previously assigned by an equivalent PLMN, if available; and<br />
# a valid 5G-GUTI that was previously assigned by any other PLMN, if available;<br />
<br />
<li>if:<br />
# the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same PLMN with which the UE is performing the registration, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or<br />
# the UE is registering with a SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by the same SNPN with which the UE is performing the registration, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;</li><br />
<br />
<li>if the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by an equivalent PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE;</li><br />
<br />
<li>if:<br />
# the UE is registering with a PLMN and the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other PLMN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE; or<br />
# the UE is registering with an SNPN, the UE holds a valid 5G-GUTI that was previously assigned, over 3GPP access or non-3GPP access, by any other SNPN, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE and shall additionally include the NID of the other SNPN in the NID IE;</li><br />
<br />
<li>if a SUCI other than an onboarding SUCI is available, and the UE is not initiating the initial registration for onboarding services in SNPN, the UE shall include the SUCI other than an onboarding SUCI in the 5GS mobile identity IE;</li><br />
<li>if the UE does not hold a valid 5G-GUTI or SUCI other than an onboarding SUCI, and is initiating the initial registration for emergency services, the PEI shall be included in the 5GS mobile identity IE; and</li><br />
<li>if the UE is initiating the initial registration for onboarding services in SNPN, an onboarding SUCI shall be included in the 5GS mobile identity IE.</li><br />
</ol><br />
:NOTE 2: The AMF in ON-SNPN uses the onboarding SUCI as specified in 3GPP TS 23.501.<br />
<br />
If the SUCI is included in the 5GS mobile identity IE and the timer T3519 is not running, the UE shall start timer T3519 and store the value of the SUCI sent in the REGISTRATION REQUEST message. The UE shall include the stored SUCI in the REGISTRATION REQUEST message while timer T3519 is running.<br />
<br />
If the UE is operating in the dual-registration mode and it is in EMM state EMM-REGISTERED, the UE shall include the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state".<br />
<br />
:NOTE 3: Inclusion of the UE status IE with this setting corresponds to the indication that the UE is "moving from EPC" as specified in 3GPP TS 23.502.<br />
:NOTE 4: The value of the 5GMM registration status included by the UE in the UE status IE is not used by the AMF.<br />
<br />
If the last visited registered TAI is available, the UE shall include the last visited registered TAI in the REGISTRATION REQUEST message.<br />
<br />
If the UE requests the use of SMS over NAS, the UE shall include the 5GS update type IE in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS supported". When the 5GS update type IE is included in the REGISTRATION REQUEST for reasons other than requesting the use of SMS over NAS, and the UE does not need to register for SMS over NAS, the UE shall set the SMS requested bit of the 5GS update type IE to "SMS over NAS not supported" in the REGISTRATION REQUEST message.<br />
<br />
See spec for more info...<br />
<br />
...<br />
<br />
If the UE does not have a valid 5G NAS security context, <span style="color:red">the UE shall send the REGISTRATION REQUEST message without including the NAS message container IE.</span> The UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs and non-cleartext IEs, if any) in the NAS message container IE that is sent as part of the SECURITY MODE COMPLETE message as described in subclauses 4.4.6 and 5.4.2.3.<br />
<br />
If the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6. If the UE does not need to send non-cleartext IEs, the UE shall send a REGISTRATION REQUEST message without including the NAS message container IE.<br />
<br />
<br />
...<br />
<br />
== 8.2 5GS mobility management messages ==<br />
<br />
=== 8.2.6 Registration Request ===<br />
<br />
==== 8.2.6.1 Message definition ====<br />
The REGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.6.1.1.<br />
;Message type:REGISTRATION REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
{| class="wikitable"<br />
|+ Table 8.2.6.1.1: REGISTRATION REQUEST message content<br />
|-<br />
! IEI !! Information Element !! Type/Reference !! Presence !! Format !! Length<br />
|-<br />
| || Extended protocol discriminator || Extended Protocol discriminator 9.2 || M || V || 1<br />
|-<br />
| || Security header type || Security header type 9.3 || M || V || 1/2<br />
|-<br />
| || Spare half octet || Spare half octet 9.5 || M || V || 1/2<br />
|-<br />
| || Registration request message identity || Message type 9.7 || M || V || 1<br />
|-<br />
| || 5GS registration type || 5GS registration type 9.11.3.7 || M || V || 1/2<br />
|-<br />
| || ngKSI || NAS key set identifier 9.11.3.32 || M || V || 1/2<br />
|-<br />
| || <span style="color:red">5GS mobile identity</span> || <span style="color:red">5GS mobile identity 9.11.3.4</span> || M || LV-E || 6-n<br />
|-<br />
| C- || Non-current native NAS key set identifier || NAS key set identifier 9.11.3.32 || O || TV || 1<br />
|-<br />
| 10 || 5GMM capability || 5GMM capability 9.11.3.1 || O || TLV || 3-15<br />
|-<br />
| 2E || UE security capability || UE security capability 9.11.3.54 || O || TLV || 4-10<br />
|-<br />
| 2F || Requested NSSAI || NSSAI 9.11.3.37 || O || TLV || 4-74<br />
|-<br />
| 52 || Last visited registered TAI || 5GS tracking area identity 9.11.3.8 || O || TV || 7<br />
|-<br />
| 17 || S1 UE network capability || S1 UE network capability 9.11.3.48 || O || TLV || 4-15<br />
|-<br />
| 40 || Uplink data status || Uplink data status 9.11.3.57 || O || TLV || 4-34<br />
|-<br />
| 50 || PDU session status || PDU session status 9.11.3.44 || O || TLV || 4-34<br />
|-<br />
| B- || MICO indication || MICO indication 9.11.3.31 || O || TV || 1<br />
|-<br />
| 2B || UE status || UE status 9.11.3.56 || O || TLV || 3<br />
|-<br />
| 77 || Additional GUTI || 5GS mobile identity 9.11.3.4 || O || TLV-E || 14<br />
|-<br />
| 25 || Allowed PDU session status || Allowed PDU session status 9.11.3.13 || O || TLV || 4-34<br />
|-<br />
| 18 || UE's usage setting || UE's usage setting 9.11.3.55 || O || TLV || 3<br />
|-<br />
| 51 || Requested DRX parameters || 5GS DRX parameters 9.11.3.2A || O || TLV || 3<br />
|-<br />
| 70 || EPS NAS message container || EPS NAS message container 9.11.3.24 || O || TLV-E || 4-n<br />
|-<br />
| 74 || LADN indication || LADN indication 9.11.3.29 || O || TLV-E || 3-811<br />
|-<br />
| 8- || Payload container type || Payload container type 9.11.3.40 || O || TV || 1<br />
|-<br />
| 7B || Payload container || Payload container 9.11.3.39 || O || TLV-E || 4-65538<br />
|-<br />
| 9- || Network slicing indication || Network slicing indication 9.11.3.36 || O || TV || 1<br />
|-<br />
| 53 || 5GS update type || 5GS update type 9.11.3.9A || O || TLV || 3<br />
|-<br />
| 41 || Mobile station classmark 2 || Mobile station class mark 2 9.11.3.31C || O || TLV || 5<br />
|-<br />
| 42 || Supported codecs || Supported codec list 9.11.3.51A || O || TLV || 5-n<br />
|-<br />
| 71 || NAS message container || NAS message container 9.11.3.33 || O || TLV-E || 4-n<br />
|-<br />
| 60 || EPS bearer context status || EPS bearer context status 9.11.3.23A || O || TLV || 4<br />
|-<br />
| 6E || Requested extended DRX parameters || Extended DRX parameters 9.11.3.26A || O || TLV || 3<br />
|-<br />
| 6A || T3324 value || GPRS timer 3 9.11.2.5 || O || TLV || 3<br />
|-<br />
| 67 || UE radio capability ID || UE radio capability ID 9.11.3.68 || O || TLV || 3-n<br />
|-<br />
| 35 || Requested mapped NSSAI || Mapped NSSAI 9.11.3.31B || O || TLV || 3-42<br />
|-<br />
| 48 || Additional information requested || Additional information requested 9.11.3.12A || O || TLV || 3<br />
|-<br />
| 1A || Requested WUS assistance information || WUS assistance information 9.11.3.71 || O || TLV || 3-n<br />
|-<br />
| A- || N5GC indication || N5GC indication 9.11.3.72 || O || TV || 1<br />
|-<br />
| 30 || Requested NB-N1 mode DRX parameters || NB-N1 mode DRX parameters 9.11.3.73 || O || TLV || 3<br />
|-<br />
| 29 || UE request type || UE request type 9.11.3.76 || O || TLV || 3<br />
|-<br />
| 28 || Paging restriction || Paging restriction 9.11.3.77 || O || TLV || 3-35<br />
|-<br />
| 72 || Service-level-AA container || Service-level-AA container 9.11.2.10 || O || TLV-E || 6-n<br />
|-<br />
| 32 || NID || NID 9.11.3.79 || O || TLV || 8<br />
|-<br />
| 16 || MS determined PLMN with disaster condition || PLMN identity 9.11.3.85 || O || TLV || 5<br />
|-<br />
| 2A || Requested PEIPS assistance information || PEIPS assistance information 9.11.3.80 || O || TLV || 3-n<br />
|}<br />
<br />
See spec for details of each message.<br />
<br />
==== 8.2.6.21 NAS message container ====<br />
This IE shall be included if the UE is sending a REGISTRATION REQUEST message as an initial NAS message, the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs.<br />
<br />
=== 8.2.12 De-registration request (UE originating de-registration) ===<br />
<br />
==== 8.2.12.1 Message definition ====<br />
The DEREGISTRATION REQUEST message is sent by the UE to the AMF. See table 8.2.12.1.1.<br />
<br />
;Message type:DEREGISTRATION REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
=== 8.2.16 Service request ===<br />
<br />
==== 8.2.16.1 Message definition ====<br />
The SERVICE REQUEST message is sent by the UE to the AMF in order to request the establishment of an N1 NAS signalling connection and/or to request the establishment of user-plane resources for PDU sessions which are established without user-plane resources. See table 8.2.16.1.1.<br />
<br />
;Message type:SERVICE REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
=== 8.2.30 Control Plane Service request ===<br />
<br />
==== 8.2.30.1 Message definition ====<br />
The CONTROL PLANE SERVICE REQUEST message is sent by the UE to the AMF when the UE is using 5GS services with control plane CIoT 5GS optimization. See table 8.2.30.1.1.<br />
<br />
;Message type:CONTROL PLANE SERVICE REQUEST<br />
;Significance:dual<br />
;Direction:UE to network<br />
<br />
See spec for details...<br />
<br />
== 9.1 General message format and information elements coding Overview ==<br />
See spec for details of section 9.<br />
<br />
=== 9.1.1 NAS message format ===<br />
<br />
Within the protocols defined in the present document, every 5GS NAS message is a standard L3 message as defined in 3GPP TS 24.007.<br />
<br />
== 9.11 Other information elements ==<br />
<br />
=== 9.11.1 General ===<br />
<br />
<span style="color:red">The different formats (V, LV, T, TV, TLV, LV-E, TLV-E) and the five categories of information elements (type 1, 2, 3, 4 and 6) are defined in 3GPP TS 24.007.</span><br />
<br />
The first octet of an information element in the non-imperative part contains the IEI of the information element. If this octet does not correspond to an IEI known in the message, the receiver shall determine whether this IE is of type 1 or 2 (i.e., it is an information element of one octet length) or an IE of type 4 (i.e., that the next octet is the length indicator indicating the length of the remaining of the information element) (see 3GPP TS 24.007).<br />
<br />
This allows the receiver to jump over unknown information elements and to analyze any following information elements of a particular message.<br />
<br />
The definitions of information elements which are:<br />
<ol type="a"><br />
<li>common for the 5GMM and 5GSM protocols;</li><br />
<li>used by access stratum protocols; or</li><br />
<li>sent to upper layers</li><br />
</ol><br />
are described in subclause 9.11.2.<br />
<br />
The information elements of the 5GMM or 5GSM protocols can be defined by reference to an appropriate specification which provides the definition of the information element, e.g., "see subclause 10.5.6.3A in 3GPP TS 24.008".<br />
<br />
See spec for details...<br />
<br />
=== 9.11.3 5GS mobility management (5GMM) information elements ===<br />
<br />
See spec for details...<br />
<br />
==== <span style="color:red">9.11.3.4 5GS mobile identity</span> ====<br />
<br />
<span style="color:red">The purpose of the 5GS mobile identity information element is to provide either the SUCI, the 5G-GUTI, the IMEI, the IMEISV, the 5G-S-TMSI, the MAC address or the EUI-64.</span><br />
<br />
The 5GS mobile identity information element is coded as shown in figures 9.11.3.4.1, 9.11.3.4.2, 9.11.3.4.3, 9.11.3.4.4, 9.11.3.4.5, 9.11.3.4.6, 9.11.3.4.8 and 9.11.3.4.7, and table 9.11.3.4.1.<br />
<br />
The 5GS mobile identity is a type 6 information element with a minimum length of 4.<br />
<br />
See spec for figures and details...<br />
<br />
<br />
<center>[[Telecommunications info|To Telecommunications info]]</center></div>Paul