7 Procedures and information flows for PN access control
23.2593GPPPersonal Network Management (PNM)Procedures and information flowsRelease 17Stage 2TS
7.1 General
Upon receiving a UE-terminating initial request, the PNM AS shall first check whether the request originates from another PN UE within the same PN as the terminating PN UE and if so the PNM AS shall allow the session establishment to continue. If the request does not originate from another PN UE within the same PN as the terminating PN UE the PNM AS shall invoke the PN access control application if it is enabled. If no access control list exists for the terminating UE, and if the PNM AS does not invoke the PN UE redirection for the terminating UE, the PNM AS sends the initial request to the terminating UE (i.e., a UE of a PN). Otherwise, the PNM AS verifies whether the originating UE of the initial request is a valid entry contained in the PN access control list for the terminating UE, before it initiates session towards the terminating UE. With a successful verification, the PNM AS sends the initial request to the terminating UE. With an unsuccessful verification, if the terminating UE is not a controllee UE, then the PNM AS rejects the initial request. If the terminating UE is a controllee UE, the PNM AS queries the controller UE whether the session to the controllee UE is allowed to be established. If it is allowed, and if the PNM AS does not invoke the PN UE redirection for the terminating UE, the PNM AS sends the initial request to the controllee UE. Otherwise, the PNM AS rejects the initial request. Figure 7.1-1 gives a snapshot of the scenario.
Figure 7.1-1: Overview of privacy based access control Procedures and Information Flows
NOTE: The Solid line refers to access control handled by the PNM AS itself, since the identity of the originating caller is present in the access control list of the PNM AS. The dashed line refers to access control handled by the controller UE when the identity of the caller is not present in the access control list of the PNM AS.
The procedures at the PNM AS to accomplish the PN access control execution are described with the assistance of figure 7.1-2.
When the PNM AS receives a SIP initial request and its PN access control logic is switched-on, if the Request URI of the initial request identifies with the controllee UE(s), the PNM AS shall further decide whether the Request URI uniquely identify a controllee UE within a PN:
1) if a controllee UE is uniquely identifiable, the PNM AS shall check whether the Caller is in the PN access control list;
a) if the Caller is in the PN access control list, the PNM AS shall send the initial request to the controllee UE;
b) if the Caller is not in the PN access control list,
i) if there is no need to interrogate the controller UE, the PNM AS shall reject the initial request;
ii) if there is a need to interrogate the controller UE, the PNM AS shall interrogate the controller UE and handle the initial request message based on the interrogation results from the PN-user.
Editor’s note: The use of GRUU as described in 3GPP TS 23.228 [4] can assist the PNM AS with uniquely identifying a controllee UE.
2) if a controllee UE is not uniquely identifiable, the PNM AS shall perform the PN access control without invoking the controller UE (i.e., without any PN-user interaction) and check whether the Caller is in the PN access control list;
a) if the Caller is in the PN access control list, the PNM AS shall send the initial request back to the S-CSCF (see 3GPP TS 23.228 [4]);
b) if the Caller is not in the PN access control list, the PNM AS shall reject the initial request.
Figure 7.1-2: PN access control execution flow at the PNM AS (AC and ACL stand for Access Control and Access Control List, respectively)
7.2 PN access control procedures in the IM CN subsystem
Without lack of generality, the following assumptions have been made with respect to the terminals and the network.
<Assumptions related to identities of UEs>
– PN-user 1 has two UEs – UE 1a & UE 1b in the PN, containing identities user1_public1@home1.net and user1_public2@home1.net respectively, and having a subscription with the home network providing PNM service.
– UE 1b is configured as controllee UE and UE 1a as controller UE by the PN-user 1.
– The originating UE which initiates the request may belong to the same/different network where the PNM AS is located. The originating UE of the initial request needs not be aware of the setting of the access control done by PN-user 1.
– PN-user 1has configured UE2 with user2_public@home2.net as the only entry in the access control list related to the controllee UE in this example. When the PNM AS receives initial requests not coming from UE2, the PNM AS can query the controller UE and the continuation of the initial request depends on the outcome of the query.
– The following table summarizes the above assumptions.
Table 1: Example of a simple access control table PN
|
PN Of user |
controllee UE |
controller UE |
Access List entries |
|
(UE 1a) user1_public1@home1.net |
No |
N/A |
N/A |
|
(UE 1b) user1_public2@home1.net |
Yes |
UE 1a |
(UE 2) user2_public@home2.net |
<Network assumptions>
– PN-user’s home network provides PN access control, which allows PN-users to configure identities (e.g., a SIP URI) which are permitted to initiate sessions to the UE of the PN.
– This service is hosted by the PNM Server which is a SIP application server, serving scscf#1.
– For simple illustration, in this example, both identities of the PN are shown to be registered with the same S-CSCF (S-CSCF#1) to improve efficiency in signalling, which might be the case in most implementations.
– The PNM AS stores access control lists of controllee UE and the controller UE can process access control requests during dynamic procedures.
UE 3 sends an initial request to UE 1b (user1_public2@home1.net). But, UE 3 hasn’t been configured by the PN-user in the access control list. Therefore, the PN MAS queries the controller UE (i.e., UE 1a) about the information as to how to process this initial request.
7.3 PN access control procedure in the IM CN subsystem
7.3.1 General
An inherent problem in the Access control list case is the need for the PN-user to configure each originating UE that the PN-user feels appropriate. This may not be a scalable solution where tens of UEs may try to access the controllee UE. In order to solve this problem, the PN-user may configure a controller UE, after processing of this decision normal session initiation procedures may be continued. Once the controller UE has been chosen, to handle all session initiation requests from UEs whose identities are not configured in the access control list, a query can be directed to the particular controller UE.
The controller UE in turn is capable of checking the access control information of this query. Options may be given to the PN-user to either accept the call himself, or answer the query by allowing the call to go through to the intended destination (controllee UE) or deny the call. In addition the user may be given an option of saving this policy for future call requests by the same source. Once the user makes the decision, a response message carrying this information may be sent directing the session back to the original destination.
The PNM AS receives the response message from the S-CSCF. If the decision of the PN-user was to allow the call, it sends the original initial request message. If required to save (based on user response) it saves the settings for the originating UE in the access control list
7.3.2 PN access control based on query logic in the IM CN subsystem
In figure 7.3.2-1 it is assumed that the originating UE (i.e., UE 3) is not configured in the access control list of the controllee UE (i.e., UE 1b). When the PNM AS receives an Initial Request from S-CSCF# 1, the PNM AS verifies whether UE 3 matches an entry in the access control list of UE 1b. In this case, the PNM AS sends a Query to the controller UE1a to determine the handling.
Figure 7.3.2-1: High level sequence of PN access control
1. UE 3 sends an Initial Request towards UE 1b.
2. S‑CSCF#1 invokes whatever service logic is appropriate for this session setup attempt.
3. In this case, the initial filter criterion is triggered and the initial request message is forwarded to the corresponding PNM AS.
4. The PNM AS receives the initial request and the privacy mode processing is executed.
The PNM AS extracts the source and destination addresses. It confirms that the destination UE is a controllee UE. Using this as a key, it searches its database for the particular PN to find if UE 3 is configured in the access control list as allowed to initiate sessions with UE 1b.
If the originating UE has been configured in the access control list, normal processing is continued. If there is no information regarding the address of the originating UE, the PNM AS may then send a Query to the controller UE, i.e., UE 1a in this example, containing the access request of UE 1b by UE 3. This Query can be processed by UE 1a.
5. As a result of Step 4, the PNM AS queries the controller UE about the information of how to precede with the Initial Request by sending a Query to S-CSCF#1.
6. S‑CSCF#1 validates the service profile, and invokes any termination service logic required for UE 1a and forwards the Query to UE 1a.
7. In the privacy decision processing, the information contained in the Query is indicated to the PN-user. (Example: UE 3 calling UE 1b, 1: Allow, 2: Deny 3: Allow and save policy 4: Deny and save policy 5: Accept). The PN-user may then allow/disallow and possibly save this option for future calls. This information is sent in the Query Response.
8. The decision of the user is sent in the Query Response.
9. The S‑CSCF#1 forwards the Query Response towards the PNM AS.
10. In the privacy response processing step, the PNM AS determines the action directed by the user. If the PN-user has allowed the Initial Request to pass to the UE 1b, the Initial Request is sent to UE 1b.
NOTE 1: If the user has chosen to save the policy, the policy is stored in the access control list of the controllee UE using the PN-configuration procedure.
11. The PNM AS sends the original Initial Request to the S-CSCF#1
12. The S-CSCF#1 forwards the initial request message to UE 1b.
NOTE 2: Interaction with other services; The privacy service is to authorize the call where the authorization apart from normal authorization procedures involved in the network, requires real time consent from the user. All other supplementary features or other services may follow once this authorization is received.
7.3.3 PN access control based on access control lists
In figure 7.3.3-1 it is assumed that the originating UE (i.e., UE 2) is configured in the access control list of the controllee UE (i.e., UE 1b). When the PNM AS receives an Initial Request from S-CSCF# 1, the PNM AS verifies whether UE 2 matches an entry in the access control list of UE 1b. In this case, the PNM AS sends the Initial Request message to UE 1b.
Figure 7.3.3-1: PN access control in case of PNM AS alone
1. S-CSCF#1 receives an Initial Request from UE 2 to UE 1b.
2. S-CSCF#1 invokes the termination service control logic required for the UE 1b and evaluates the initial filter criteria.
3. S-CSCF#1 forwards the Initial Request to the PNM AS as a result of executing the initial filter criteria.
4. In the privacy mode processing step, the PNM AS extracts the source and destination addresses. It confirms that UE 1b is a controllee UE. Using this as a key, it searches its database for the PN of UE 1b to find if UE 2 is configured in the access control list. In this case, it is assumed that UE 2 is allowed to initiate sessions with UE 1b.
5. The PNM AS sends the Initial Request message to the S-CSCF#1.
6. The S-CSCF#1 routes the Initial Request message to the UE 1b.
In figure 7.3.3-2 it is assumed that the originating guest UE (i.e., UE 2) is configured in the access control list of the controllee PNE (i.e., PNE-1). UE1b and PNE-1 form a PAN. When the PNM AS receives an Initial Request from S-CSCF# 1, the PNM AS verifies whether UE 2 matches an entry in the access control list of PNE-1. In this case, the PNM AS sends the Initial Request message to the PNE-1 via UE 1b.
Figure 7.3.3-2: PNE access control
1. S-CSCF#1 receives an Initial Request from UE 2 containing the identity of PNE-1.
2. S-CSCF#1 invokes the termination service control logic required and evaluates the initial filter criteria.
3. S-CSCF#1 forwards the Initial Request to the PNM AS as a result of executing the initial filter criteria.
4. In the privacy mode processing step, the PNM AS extracts the source and destination addresses. It confirms that PNE-1 is a controllee PNE. Using this as a key, it searches its database for the PN of PNE to find if UE 2 is configured in the access control list. In this case, it is assumed that UE 2 is allowed to initiate sessions with PNE-1.
5. The PNM AS sends the Initial Request message to the S-CSCF#1.
6. PNE-1 accesses the network via UE1b, then the S-CSCF#1 routes the Initial Request message to the UE 1b.
7. The UE1b sends the Initial Request message to the PNE-1 via the PAN internal interface.
7.4 PN access control procedure in the CS domain
7.4.1 General
PN access control deals with a user having access control over his Personal Network, wherein he may restrict access to his UEs. These UEs of the PN, over which access control has been enabled, are configured as controllee UE. To initiate sessions with these controllee UEs, the originating UEs need to be configured by the PN-user in a PN access control list. For information regarding the originating UEs that are configured in the PN access control list, which is the case in majority of the scenarios, the user nominates a controller UE to handle the access control. In this case, the network queries the user whether the call to the controllee UE may be allowed to go through. If the user allows it, the network allows the call to go through.
7.4.2 PN access control procedure (When the caller is not in the PN access control list)
If the caller is not in the PN access control list the gsmSCF interacts with the controller UE in order to route the call to the Controllee UE. Figure 7.4.2-1 shows the implementation of access control procedure in CS domain when the caller is not in PN access control list.
Figure 7.4.2-1: PN access control Procedure in CS domain
1. A call request to the UE located in PN containing the MSISDN of the UE arrives at the GMSC.
2. GMSC queries the HSS for routing Information by sending MAP SRI.
3. HSS checks the subscription information for the called party. Further the HSS provides the information for the PNM subscriber including the T-CSI. The HSS returns the T-CSI to the GMSC in the response (MAP-SRI-ACK)
4. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP to gsmSCF.
5-7. The gsmSCF executes the PN access control logic and will check with the controller UE about the acceptability of call request by sending USSD request message to the controller UE via HSS and MSC/VLR.
NOTE: This USSD message includes the call Information such as the public user Identity of caller and terminating UE.
8. The controller UE displays the text provided and awaits user input. The user decides whether the call request is allowed or not and accordingly the controller UE will send the USSD response message to MSC/VLR.
9-10. The MSC/VLR will forward this USSD response message to gsmSCF via HSS.
11. The gsmSCF will continue the call or release the call by sending the CAMEL continue message/release call message to the GMSC according to the controller UE’s response Based on the decision by the controller UE the call will established or released.
Figure 7.4.2-2 provides a solution for the time delay problem which can occur during interaction between the network and the controller UE.
Figure 7.4.2-2: PN access control procedure in CS domain with delay handling.
1. A call request to a UE containing the MSISDN of the UE arrives at the GMSC.
2. The GMSC queries the HSS for routing Information by sending MAP SRI.
3-4 The HSS checks the subscription information for the called party. Further the HSS provides the information for the PNM subscriber including the T-CSI. The HSS returns the T-CSI to the GMSC in the response.
5. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP to gsmSCF.
6. & 8-10 The gsmSCF executes the PN access control logic and will check with the controller UE about the acceptability of the call request by sending USSD request message to the controller UE via HSS and MSC/VLR.
NOTE: This USSD message includes the call Information such as the public user Identity of the originating and the terminating UE.
7. The gmsSCF will start the Timer.
11. Supervision of the started timer by the gsmSCF.
12-13. If the time out occurs because no response from the controller UE, the gsmSCF will send the Play Announcement message to the GMSC and the GMSC will send an early ACM to the originating UE.
NOTE: Step 12-13 can be skipped if the controller UE responds before timer out occurs. No ACM will be send.
14. The controller UE displays the text provided and awaits user input. The user decides whether the call request is allowed or not and accordingly the controller UE will send the USSD response message to MSC/VLR.
15-16. The MSC/VLR will forward this USSD response message to the gsmSCF via the HSS.
17. The gsmSCF will send a message to GMSC to stop playing the announcement if it is generated. The gsmSCF will continue the call or release the call by sending the CAMEL continue message/release call message to the GMSC according to the controller UE’s response.
7.4.3 PN access control procedure in CS domain (When the caller is in the PN access control list)
Figure 7.4.3-1 shows the PN access control procedure when the caller is in PN access control list.
Figure 7.4.3-1 PN access control procedure in the CS domain (Caller is in the PN access control list)
1. A call request to the PN UE containing the MSISDN of the UE arrives at the GMSC.
2. The GMSC queries the HSS for routing Information by sending MAP SRI.
3-4. The HSS checks the subscription information for the called party. Further the HSS provides the information for the PNM subscriber including the T-CSI. The HSS returns the T-CSI to the GMSC in the response.
5. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP to gsmSCF.
6. The gsmSCF executes the PN access control logic for access control procedure. The calling party is part of the access control list for this PN.
7. Based on the positive result, the gsmSCF send the CAMEL CONTINUE message to GMSC to continue the call.
8. The GMSC queries the HSS for routing Information by sending MAP SRI with ‘Suppress T‑CSI’ set.
9. The HSS returns the retrieved MSRN to the GMSC in response by sending MAP SRI_ACK.
10. The GMSC generates a call request message containing MSRN and sends it to MSC/VLR.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2007-02 |
Skeleton of the TS (C1-070122) |
– |
0.0.0 |
||||
|
2007-02 |
Version 0.1.0 created as a result of incorporating the following contributions at CT1#45. C1-070568 – Personal UE Networks management -UE registration procedure C1-070569 – Personal UE Networks Management – UE activation procedure |
0.0.0 |
0.1.0 |
||||
|
2007-03 |
Version 0.2.0 created as a result of incorporating the following contributions at CT1#46. C1-070655 – CR against TS 23.259 Clause 2 References C1-070906 – CR against TS 23.259 Clause 6.4 C1-071005 – CR against TS 23.259 Clause 7 Procedures and Information Flows for Private Network Services |
0.1.0 |
0.2.0 |
||||
|
2007-05 |
Version 0.3.0 created as a result of incorporating the following contributions at CT1#47. C1-071073 – Discussion on no re-invoking of PNM AS after session/call redirection |
0.2.0 |
0.3.0 |
||||
|
2007-08 |
Version 0.4.0 created as a result of incorporating the following contributions at CT1#48. C1-071645 – PNM private network service C1-072004 – CR against TS 23.259 Clause 6.1.3 Procedures and Information Flows for PN-Registration and PN-Deregistration in CS Domain C1-072007 – CR against TS 23.259Procedures and Information Flows for Domain Interworking in PNM Session Redirection C1-072010 – PNM IMPI C1-072011 – PNM Query C1-072100 – Information message in PNM message C1-072101 – Clarification to UEs in the Configuration Request C1-072171 – Access control procedures in the CS domain |
0.3.0 |
0.4.0 |
||||
|
2007-09 |
Version 1.0.0 created for presentation to TSG |
0.4.0 |
1.0.0 |
||||
|
2007-10 |
C1-072242 – Overview of PNM in the CS domain C1-072543 – No Re-invoking of PNM CAMEL service after Session Redirection in the CS domain C1-072544 – No Re-invoking of PNM AS after Session/Call Redirection in the IM CN subsystem C1-072547 – PN Access Control List Configuration C1-072548 – Access Control in CS domain(Caller is in Access List) C1-072694 – TS23.259-100-cleanup C1-072719 – Information Message in CS domain C1-072720 – Access Control Procedure in CS domain to Avoid the Call release |
1.0.0 |
1.1.0 |
||||
|
2007-11 |
C1-072780 – TS 23.259 Subclause 7.4 update CS domain C1-073086 – PN-registration C1-073087 – PN-configuration C1-073088 – Cleanup C1-073090 – GRUU in reg event package C1-073091 – Using GRUU in the PN UE redirection C1-073092 – PN UE redirection based on UE priority |
1.1.0 |
1.2.0 |
||||
|
2008-02 |
C1-080187 – PN Configuration Procedures Editorials C1-080188 – PN Registration and Configuration Restructuring C1-080237 – Clause 6 Update C1-080458 – Clarifying PNM Scope C1-080461 – Error procedures for the priority handling of the session redirection in IMS C1-080462 – Error procedures for the priority handling of the session redirection in the CS domain C1-080463 – PN Configuration Consolidation C1-080465 – PNM AC Logic C1-080573 – PN Access Control Cleanup |
1.2.0 |
1.3.0 |
||||
|
2008-03 |
CT#39 |
CP-080076 |
Version 2.0.0 created by MCC for presentation to CT#39 for approval |
1.3.0 |
2.0.0 |
||
|
2008-03 |
Version 2.0.0 approved in CT#39 and version 8.0.0 created by MCC for publication |
2.0.0 |
8.0.0 |
||||
|
2008-06 |
CT#40 |
CP-080352 |
0004 |
1 |
Domain Interworking Update |
8.0.0 |
8.1.0 |
|
2008-12 |
CT#42 |
CP-080859 |
0005 |
3 |
PNM Closed User Group functionality |
8.1.0 |
8.2.0 |
|
2008-12 |
CT#42 |
Editorial clean up by MCC |
8.1.0 |
8.2.0 |
|||
|
2009-06 |
CT#44 |
CP-090431 |
0007 |
1 |
Scope of Rel-9 TS 23.259 |
8.2.0 |
9.0.0 |
|
2009-09 |
CT#45 |
CP-090683 |
0009 |
1 |
Procedures of TE registration |
9.0.0 |
9.1.0 |
|
2009-09 |
CT#45 |
CP-090683 |
0010 |
1 |
Procedures of PNE configuration |
9.0.0 |
9.1.0 |
|
2009-09 |
CT#45 |
CP-090683 |
0011 |
1 |
Definitions Update |
9.0.0 |
9.1.0 |
|
2009-09 |
CT#45 |
CP-090683 |
0012 |
1 |
Procedures of PNE redirection |
9.0.0 |
9.1.0 |
|
2009-09 |
CT#45 |
CP-090683 |
0013 |
1 |
Procedures of PNE Access Control |
9.0.0 |
9.1.0 |
|
2009-12 |
CT#46 |
CP-090924 |
0014 |
1 |
Corrections to TS 23.259 |
9.1.0 |
9.2.0 |
|
2009-12 |
CT#46 |
CP-090924 |
0015 |
1 |
Editorial corrections |
9.1.0 |
9.2.0 |
|
2009-12 |
CT#46 |
CP-090924 |
0022 |
2 |
Addition of PN-deregistration procedure for PNE |
9.1.0 |
9.2.0 |
|
2009-12 |
CT#46 |
Editorial cleanup by MCC |
9.1.0 |
9.2.0 |
|||
|
2010-03 |
CT#47 |
CP-100136 |
0023 |
1 |
PNE definition in 23.259 |
9.2.0 |
9.3.0 |
|
2010-03 |
CT#47 |
CP-100136 |
0024 |
1 |
Addtion of the general description of PN-deregistration procedure for PNE |
9.2.0 |
9.3.0 |
|
2010-03 |
CT#47 |
CP-100237 |
0025 |
1 |
Update the scope of PAN |
9.2.0 |
9.3.0 |
|
2010-06 |
CT#48 |
CP-100356 |
0027 |
1 |
Correction of PNE registration |
9.3.0 |
9.4.0 |
|
2011-03 |
CT#51 |
Upgrade to Rel-10 by MCC |
9.4.0 |
10.0.0 |
|||
|
2012-09 |
CT#57 |
Upgrade to Rel-11 by MCC |
10.0.0 |
11.0.0 |
|||
|
2014-09 |
CT#65 |
Upgrade to Rel-12 by MCC |
11.0.0 |
12.0.0 |
|||
|
2015-12 |
CT#70 |
Upgrade to Rel-13 by MCC |
12.0.0 |
13.0.0 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
CT-75 |
– |
– |
– |
Update to Rel-14 version (MCC) |
14.0.0 |
|
|
2018-10 |
Upgrade to Rel-15 version (MCC) |
15.0.0 |
|||||
|
2020-07 |
SA-88e |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
SA-95e- |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |