10 Roles for PN access control

24.2593GPPPersonal Network Management (PNM)Release 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.1 Introduction

The PN access control procedure enables the controller UE to exercise access control to restrict accesses to certain PN controllee UE(s) of the PN, or certain controllee PNE(s) other than the UE as described in 3GPP TS 23.259 [15].

10.2 PN UE

When the PN UE that supports the PN controller functionality and that is configured to act as a PN controller receives an initial request containing an Accept-Contact header containing a g.3gpp.iari_ref feature tag containing the IARI value defined in subclause 10.4 and a target URI-parameter in the Request-URI, then the PN UE shall perform the PN controller function and indicate to the user that the PN controller UE has received a request for the PN controllee UE, otherwise the PN UE shall not perform the PN controller function and shall follow the UE terminating case procedures in 3GPP TS 24.229 [3].

When performing the PN controller function the PN UE shall:

a) indicate the PN controllee UE indicated by the URI in the target URI-parameter contained in the Request-URI;

b) indicate the identity of the originating user indicated in the P-Asserted-Identity header.

The PN UE may offer the user the following options:

a) allow the request to be forwarded to the PN controllee UE;

b) deny the request (i.e reject the session);

c) accept the request (i.e establish the session).

When allowing the request to be forwarded to the PN controllee UE the PN UE shall send a 302 (Moved Temporarily) response. In the 302 (Moved Temporarily) response the PN UE shall:

a) include a Contact header containing the URI from the target URI-parameter in the Request-URI of the incoming request;

b) include a History-Info header copied from the incoming request unless the user wishes not to reveal to the user of the PN controllee UE that the request was forwarded first to the PN controller UE.

When the user allows the request to be forwarded to the PN controllee UE the PN UE may allow the user to add the URI from the P-Asserted-Identity header to a <PNAccessControlList> using the procedure in subclause 7.2.

When denying the request to be forwarded to the PN controllee UE the PN UE shall send either:

a) a 480 (Temporarily Unavailable) response if the user wishes to not allow the PN controllee UE to receive requests from the originator at this time but may allow requests at some future time;

b) a 410 (Gone) response if the user wishes to not allow the PN controllee UE to receive requests from the originator at any time but wishes the originator to not know that the request was actively blocked; or

c) a 403 (Forbidden) response if the user wishes to not allow the PN controllee UE to receive requests from the originator at any time and wishes the originator to know that the request was actively blocked.

The PN UE should only send a 480 (Temporarily Unavailable) response to the PN controller request when the user has specifically denied the request as this will prevent the request being forwarded to other PN controller UEs. When the user allows the request to be forwarded to the PN controllee UE the PN UE may allow the user to add the URI from the P-Asserted-Identity header to a <PNAccessControlList> using the procedure in subclause 7.2.

When the user accepts the request the PN UE shall follow the procedures in 3GPP TS 24.229 [3].

When a PN UE that does not support the PN controller functionality or that is not configured to act as a PN controller (i.e a PN controllee UE) receives an initial request the PN UE shall follow the UE terminating case procedures in 3GPP TS 24.229 [3].

10.2A PN UE procedures supporting PNE access control

When the controllee is the PNE(s) other than the UE, the PN UE procedures in subclause 10.2 apply except that the references to "PN controllee UE" are replaced by "controllee PNE".

10.3 PNM application

10.3.1 PN access control procedure in the IM CN subsystem

When the PNM AS receives an initial request containing in the Request-URI the address of a PN UE within the same PN as the originating PN UE the PNM AS shall allow the request to continue normally.

When the PNM AS receives an initial request from a UE that is not a member of the same PN as the PN UE that’s address is contained in the Request-URI and the PN Access Control is not enabled the PNM AS shall return a 403 (Forbidden) response.

When the PNM AS receives an initial request from a UE that is not a member of the same PN as the PN UE that’s address is contained in the Request-URI and the address in the Request-URI exists in a <PNController> element in the PN access control list the PNM AS shall allow the request to continue normally.

When the PNM AS receives an initial request due to the terminating initial filter criteria, from a UE that is not a member of the same PN as the PN UE that’s address is contained in the Request-URI and the address in the Request-URI exists in a <PNControllee> element in the PN access control list the PNM AS shall verify if the address in the P-Asserted-Identity exists in a <PNAccessControlList> element in the PN access control list.

NOTE: The PNM AS is triggered first by forming the initial filter criteria in the S-CSCF.

If there is a matching <PNAccessControlList> element the PNM AS shall allow the request to continue normally.

If there is no matching <PNAccessControlList> element the PNM AS shall send an initial request of the same SIP Method on a new dialog to the URI of the PN controller UE contained in the <PNController> element if it exists. If no <PNController> element exists then the PNM AS shall return a 403 (Forbidden) response. When sending the initial request to the PN controller UE the PNM AS shall include in the request the following:

a) a Request-URI set to the SIP URI contained in the <PNController> element along with a target URI-Parameter as defined in IETF RFC 4458 [17] set to the URI from the Request-URI of the original initial request;

b) a From header set to the SIP URI of the PNM AS;

c) a To header set to the URI contained in the <PNController> element;

d) a P-Asserted-Identity header set to the contents of the P-Asserted-Identity header in the original initial request;

e) a Contact header set to the IP address or FQDN of the PNM AS;

f) a Supported header containing the option tags from the original initial request with the addition of the option tag "histinfo";

g) a History-Info header that includes as the Targeted-to-URI the URI from the Request-URI of the original initial request, and as the next branch index URI, the contents of the Request-URI of this request including the target URI-parameter along with the index parameters as specified in IETF RFC 4244 [16];

h) an Accept-Contact header containing the g.3gpp.iari_ref feature tag containing the IARI value <urn:urn-7:3gpp-application.ims.iari.PNM-Controller>.

If the PNM AS receives in response a 302 (Moved Temporarily) response the PNM AS shall redirect the original incoming request to the URI contained in the Contact header of the 302 (Moved Temporarily) response. The PNM AS shall add to the request the following:

a) a Request-URI set to the SIP URI contained in the Contact header of the 302 (Moved Temporarily) response;

b) a Supported header containing the option tags from the original initial request with the addition of the option tag "hist-info";

c) a History-Info header that includes the URIs from the History-Info header in the 302 (Moved Temporarily) response along with the contents of the Request-URI of this request as the next branch index URI under the top level Targeted-to-URI, along with the appropriate index parameter as specified in IETF RFC 4244 [16], if the 302 (Moved Temporarily) response contains a History-Info header;

If the PNM AS receives in response a 4xx (other than a 403 (Forbidden) response or 410 (Gone) response or 480 (Temporarily Unavailable) response), 5xx or 6xx response and there exist more <PNController> elements in the PN access control list which have not had the request forwarded to yet, then the PNM AS shall send an initial request of the same SIP Method on a new dialog to the URI of the PN controller UE contained in the <PNController> element as above except that the History-Info header shall include the URIs from the History-Info header in the 302 (Moved Temporarily) response and as the next branch index URI, the contents of the Request-URI of this request including the target URI-parameter along with the index parameters as specified in IETF RFC 4244 [16];

Otherwise, if there do not exist more <PNController> elements in the PN access control list which have not had the request forwarded to yet, then forward the response back towards the originator of the initial request.

If the PNM AS receives in response a 200 (OK) response, a 403 (Forbidden) response, a 410 (Gone) response or 480 (Temporarily Unavailable) response the PNM AS shall forward the response back towards the originator of the initial request.

10.3.2 PN access control procedure in the CS domain

When the PNM application receives an indication that the gsmSCF has received a CAMEL IDP message related to a terminating call, the PNM application shall:

1) check if access control is applicable on the basis of the service key and called party number received in the CAMEL IDP message.

2) if the call is not subject to access control, cause the gsmSCF to respond with a CAMEL CONTINUE and no further PNM specific procedures are performed on this call.

3) if the call is subject to access control, it causes the gsmSCF to perform as follows:

a) check if the calling party is configured in the PN access control list.

b) if the calling party is configured in the PN access control list, cause the gsmSCF to respond with a CAMEL CONTINUE message to the GMSC.

c) if the calling party is not configured in the PN access control list, cause the gsmSCF to generate the USSD request message to the controller UE.

4) based on the controller’s response cause the gsmSCF to respond with a CAMEL CONTINUE message or a CALL RELEASE message to the GMSC.

10.4 PNM controller IMS application reference identifier

The URN used to define the IARI for the PNM controller application: value urn:urn-7:3gpp-application.ims.iari.pnm-controller. The URN is registered at http://www.3gpp.com/Uniform-Resource-Name-URN-list.html.

Summary of the URN: This URN indicates that the device supports the PNM controller application

The URN is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:

– This URN is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.

Examples of typical use: Indicating that a mobile phone supports the PNM controller application.