A.2 Multiple private numbering plans
24.5243GPPArchitecture, functional description and signallingHosted enterprise servicesRelease 17TS
If the end user is entitled to use more than one private numbering plan, the UE will either proceed as above, providing that the remaining dial string contains sufficient information for the network to identify the private numbering plan being used, or determine the private numbering plan being used and send the dial string in the Request URI of SIP requests, using one of the following formats:
1) A TEL URI, complying with IETF RFC 3966 [21], with local number and a pre-configured phone-context value corresponding to the private numbering plan used.
tel:<output dial string>;phone-context=pnp-value.entreprise.com.
2) A SIP URI, complying with IETF RFC 3261 [22], with the user =phone parameter.
sip:<output dial string>;phone-context=pnp-value.entreprise.com@operator.com;user=phone.
3) A SIP URI, complying with IETF RFC 3261 [22] and IETF RFC 4967 [23], with the user =dialstring parameter (see note).
sip:<output dial string>;phone-context=pnp-value.entreprise.com@operator.com;user=dialstring.
NOTE: This option only applies if the dial string was not completely processed into a private number string.
4) A SIP URI complying with IETF RFC 3261 [22], where the user part contains the dialled string (possibly modified) and the domain name is specific enough to enable to network to understand that the user part contains a dial string according to a particular private numbering plan or private dialling plan.
sip:<output dialstring>@pnp-value.entreprise.com.
In the first three cases, the phone-context value indicates the private numbering plan the dial string belongs to.
Annex B (informative):
Scenarios for HES extension to CS users
Figure B.1 provides an overview of a functional architecture that can support a number of deployment scenarios for extending HES to CS endpoints. Functions within the dotted box in figure B.1 represent functions that may physically reside in one or more IMS application servers. For a given deployment scenario not all of the functions may be needed however to provide HES to a CS endpoint at least one AS will contain HES logic.
NOTE: A multimode UE is included in the set of endpoints a HES can serve. An example of a multimode UE is one that can assume the UE role and the Legacy Endpoint role (see figure B.1). Simultaneous connectivity to IP-CAN and CS is subject to the constraints of the access network and the UE.
Figure B.1: Functional Architecture for supporting hybrid accesses
The functional architecture shown in figure B.1 allows the following deployment scenarios:
– Scenario 1 (S1): In this scenario IN triggers in the CS network route the call to an IN SCF interacts with the HES logic. The IN SCF controls the call in the CS network as per the HES logic. For this approach both the IN SCF and HES logic are co-located in the same IMS AS.
– Scenario 2 (S2): In this scenario IN triggers in the CS network route the call to an IN SCF which has access to HES routing data. The IN SCF redirects the call to the IMS. HES are applied to the session using the ISC reference point to access the IMS logic which in turn accesses the HES logic.
– Scenario 3 (S3): In this scenario the CS network routes calls from CS users to the IMS. The mechanism by which this re-routing is achieved is out of scope of the present document. Upon entering the IMS PSI routing is used to route the call to the IMS User Equipment Emulation (UEE). The UEE is used to anchor the call in the IMS. The UEE uses IMS logic to initiate a session into the IMS on behalf of the CS endpoint. To apply HES the filter criteria for this pseudo user will include the HES. HES are invoked using the ISC reference point to access the IMS logic which in turn accesses the HES logic. For calls to the CS user, the UEE will be configured in the terminating filter criteria to be the last application in the chain.
Annex C (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
24/03/2014 |
Version for input to 3GPP CT1#86bis |
0.0.0 |
|||||
|
02/04/2014 |
Version collecting comments from 3GPP CT1#86bis |
0.0.0 |
0.1.0 |
||||
|
06/2014 |
CT-64 |
CP-140283 |
Version 1.0.0 created for presentation for information and approval |
0.1.0 |
1.0.0 |
||
|
06/2014 |
Post CT-64 |
Version 12.0.0 created after approval at CT64 |
1.0.0 |
12.0.0 |
|||
|
09/2014 |
CT-65 |
CP-140653 |
0001 |
Recognition of VINE functional in business trunking scenarios |
12.0.0 |
12.1.0 |
|
|
09/2014 |
CT-65 |
CP-140653 |
0002 |
Fixing non-specific versions of references |
12.0.0 |
12.1.0 |
|
|
12/2014 |
CT-66 |
CP-140848 |
0003 |
Use of transport functions |
12.1.0 |
12.2.0 |
|
|
12/2015 |
CT-70 |
Upgrade to Rel-13 |
12.2.0 |
13.0.0 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
CT75 |
Upgrade to Rel-14 |
14.0.0 |
||||
|
2017-06 |
CT76 |
CP-171058 |
0006 |
A |
Reference update : RFC7316 |
14.1.0 |
|
|
2018-06 |
SA-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
|
2020-07 |
SA-88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
|
2022-04 |
CT-95e |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |