Content for TS 23.228 Word version: 19.0.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9… AC.10…

J.1 General J.2 Representative AS J.2.1 Concept of Representative AS J.2.2 Procedures related to Representative AS J.3 Dynamic assignment of AS by S-CSCF caching J.3.1 Concept of Dynamic assignment of AS by S-CSCF caching J.3.2 Procedures related to Dynamic assignment of AS by S-CSCF caching
...

J Dynamic User Allocation to the Application Servers |R7| p. 257

J.1 General p. 257

The complexity of operating a network increases with the number of supported subscribers, and one contributor will be the management of allocating subscribers to the application servers for the same set of services, where there is a requirement for a user to be assigned to an application servers longer than the duration of one session. This would occur when there is data which is to be retained together with the processing resources longer than a single session.

Possible solutions described below do not require impacts on the stage 3 specifications.

J.2 Representative AS p. 257

J.2.1 Concept of Representative AS p. 257

The Representative AS is the application server which allocates the user to the application servers and keeps the user allocation information and relevant data for the service during the duration of a session or longer than that. The incoming call for the service is received and forwarded to the allocated application server by the Representative AS.

The following points are considered as requirements for the dynamic user allocation procedures using the representative AS.

The representative AS for each service is the initial contact point for all signalling. This can include ISC; and for example, Ut; and others signalling that may or may not be defined in 3GPP.
For the ISC, the representative AS is included in every message which opens a new dialogue. It is not included after the initial transaction.
For example, when the AS is to be invoked by evaluating the iFC at the S-CSCF, the address in the iFC is the address of the Representative AS.

The following Figure shows an example service deployment for three different services using the representative AS.

Reproduction of 3GPP TS 23.228, Fig. J.2.1: Dynamic User Allocation using Representative AS

Figure J.2.1: Dynamic User Allocation using Representative AS

J.2.2 Procedures related to Representative AS p. 258

Reproduction of 3GPP TS 23.228, Fig. J.2.2: Bypassing Representative AS procedure

Figure J.2.2: Bypassing Representative AS procedure

Procedure is as follows:

Step 1.

The initial SIP INVITE request is sent to S-CSCF to create a new dialogue.

Step 2.

The SIP INVITE request is forwarded to the Representative AS according to the service logic, e.g. iFC evaluation at the S-CSCF.

Step 3.

The Representative AS retrieves the user allocation information and forwards the SIP INVITE request to the AS#1 according to the allocation information. If there is no allocated AS for the user, the Representative AS allocates one.

Step 4.

The SIP INVITE request is forwarded to the AS#1. Note that the Representative AS does not record-route itself.

Step 5-7.

The SIP INVITE request is processed and results in the 200 OK response.

Step 8.

The subsequent SIP INVITE request in the same dialog is sent to the S-CSCF.

Step 9.

The SIP INVITE request is forwarded directly to the AS#1 according to the Route information in the request message.

Step 10-11.

The SIP INVITE request is processed and results in the 200 OK response.

J.3 Dynamic assignment of AS by S-CSCF caching p. 258

J.3.1 Concept of Dynamic assignment of AS by S-CSCF caching p. 258

The proposed solution "Dynamic assignment of AS by S-CSCF caching" is based on standard SIP session control combined with a new S-CSCF caching functionality. This solution is re-using the DNS (RFC 1035) mechanism, and supports only the ISC interface.

J.3.2 Procedures related to Dynamic assignment of AS by S-CSCF caching p. 259

Figure J.3.2.1 shows the procedure for allocating an AS by the first request of a service to an IMS registered user:

Reproduction of 3GPP TS 23.228, Fig. J.3.2.1: Assignment of AS via DNS query during first service request

Figure J.3.2.1: Assignment of AS via DNS query during first service request

Step 1.

After IMS registration a user sends an initial request to the S-CSCF for requesting a service (served by an AS).

Step 2.

The S-CSCF performs the DNS query on the server name and resolves one (or a prioritised list) of the IP address(es), which represents a physical or logical AS.

Step 3.

The S-CSCF caches the IP address of the assigned AS and stores it during the IMS registration period of the user.

Step 4.

The S-CSCF routes the request to the assigned AS. (Depending on the service the AS could read/write/store user data, e.g. using Sh interface).

Figure J.3.2.2 shows how subsequent service requests are routed directly to the assigned AS during the registration period of the IMS user:

Reproduction of 3GPP TS 23.228, Fig. J.3.2.2: S-CSCF has stored assigned AS for following service requests

Figure J.3.2.2: S-CSCF has stored assigned AS for following service requests

Step 5.

The IMS user requests the service again and sends an initial request to the S-CSCF.

Step 6.

The S-CSCF has stored the IP Address (or a prioritised list) of the assigned AS. There is no longer need to perform a DNS query.

Step 7.

The S-CSCF routes the request to the assigned AS. (Depending on the service the AS can reuse prior stored user data).

The AS pre-assignment and storage could be also done after downloading the service profile during the user registration procedure.