6 Access Stratum services
23.1103GPPRelease 17Services and functionsTSUniversal Mobile Telecommunications System (UMTS) access stratum
The modelling of the services follow the basic principles as set by ITU‑T Recommendation X.210 [4]. In this recommendation the following figure is given as an example for peer‑to‑peer connection‑mode services.
Figure 1: Example of a peer‑to‑peer connection‑mode service [4]
For connectionless‑mode services the basic primitives are "request" and "indication".
6.1 Service Access Points (SAPs)
The SAPs offered by the Access Stratum (AS) to the rest of the system (Non Access Stratum: NAS) are reflected in the following figure.
Figure 2: Service Access Points (SAPs) offered by the Access Stratum (AS)
For the time being, the SAPs offered be the AS are symmetric, i.e. the same SAPs are offered on the infrastructure side (CN-AS) and on the user equipment side (UE-AS). These SAPs are:
GC: General Control (see 6.1.1 for a general presentation and 6.2.2.1 for a detailed information).
Nt: Notification (see 6.1.2 for a general presentation and 6.2.2.2 for a detailed information).
DC: Dedicated Control (see 6.1.3 for a general presentation and 6.2.2.3 for a detailed information).
NOTE: Broadcast and Multicast services can not be described using the services and functions defined so far in the present document. The nature of Broadcast and Multicast services, like Cell Broadcast Service (CBS), is very different from other specified services. The following model characteristics are missing to fulfil the CBS requirements, namely:
1. CBS uses two segments with different QoS requirements to deliver CB messages to the UE:
1a. From Cell Broadcast Centre (CBC) to RNC, a SAP is required where for instance, 1 second turnaround time, interactive class, with a reliable transport is required.
1b. From RNC to UE, a SAP is required where for instance, a maximum delay of 10 seconds and a background class is required.
2. Because of (item 1), the service primitives used by each of the segments may also be different; i.e., the related SAPs to those primitives may differ in the two segments and a combination of GC, Nt, and DC SAPs requires study.
3. CBS traffic is asymmetric in nature. The communication flow is only in one direction from the CBC to the UE. There is no uplink channel needed and the UE can not initiate a communication or request specific information.
At least two changes are envisaged and thus detailed contributions are expected:
i. Introduce a new SAP type.
ii. Mapping example between the two communication segments.
Figure 2 shows also, as an example, some details of the AS architecture. The details are out of the scope of this document and are further specified in the 25-series.
This model does not exclude, nor imply, which protocol is specified between the UE-AS entity and the CN-AS entity. These protocols are ‘transparent’ for the AN, but participate in the service provided by the AS.
6.1.1 General Control SAPs
These SAPs are used to enable the Core Network to provide information and to give commands that do not relate to specific users or specific [sessions] (group calls, conference). There is typically one General Control SAP per AN/CN connection point. On the UE side, a possible model is to consider that there is a single General Control SAP in an MS.
6.1.2 Notification SAPs
These SAPs are used to broadcast data to identified Users. The typical use is for initiating paging in the AN. There is typically one Notification SAP per AN/CN connection point. On the UE side, a possible model is to consider that there is a single Notification SAP (a Paging SAP) in an MS.
6.1.3 Dedicated Control SAPs
These SAPs are used to establish, release connections with specific User Equipment, and to exchange information related to these connections. A connection is a relationship between temporary contexts respectively in the AN and in the CN. The context in the AN is initiated at the establishment of the connection, and erased when the connection is released. Several types of connections are identified, such as point connection (single user) and group connections.
There are typically a great number of Dedicated Control SAPs per AN/CN connection point. SAPs are identified by a SAPI at the AS boundary. During the lifetime of a connection, the connection can be identified unambiguously by the SAPI of the associated SAP, and the SAPI is used as a reference in the exchanges at the AS boundary on the infrastructure side.
A SAPI is used as a connection identifier allocated unambiguously to each connection during its lifetime, and used in the exchanges at the AS boundary on the infrastructure side.
On the UE side, a possible modelling is to consider that there is a single dedicated control SAP in an MS.
NOTE 1: On the UE side, an open issue is whether simultaneous services from distinct ANs can be provided to an MS. Settling this issue may lead to a different model, for instance with the possibility to have several Dedicated Control SAPs, one per AN with which an active context exists. Another issue, visible when analysing Point-to-Multipoint services in GSM, is the SAP modelling for those PTM services.
NOTE 2: The model is limited in this version to the cases where all the activity between a User Equipment and the infrastructure pertains to the same subscriber. Extension to cases with several subscriber sharing a User Equipment requires further study.
6.2 Operations
6.2.1 General
The operations are described both for the AS boundary on the Infrastructure side and on the User Equipment side. The description of the operations on the Infrastructure side is given with sufficient details to develop on this basis a concrete control protocol at the AN/CN inter-connection. The description of the operations on the User Equipment side may be used [to be discussed] for developing a concrete API, allowing an open modular design of the User Equipment software.
The operations are described in three clauses, one for operations that involve both the IF side and the UE side, one for operations local to the IF and finally one for operations local to the UE side. In each clauses, operations are sorted per SAP category.
Request and confirm primitives are always toward the Access Stratum. Indication and response primitives are always from the Access Stratum.
6.2.2 Common operations
6.2.2.1 General Control SAP
6.2.2.1.1 Information broadcast
This operation consists in the broadcast from IF toward User Equipment of some information in some geographical area. This information is to be used by the User Equipment for instance to choose among access points or to be taken into account during initial access. The information can also be destinated to an application.
NOTE: This concerns only information to be broadcasted on behalf of Non Access Strata. Other information may be broadcasted for the internal use of the Access Stratum.
6.2.2.1.1.1 Information broadcast request, IF side
The parameters are:
|
Category |
enumerated (access point selection, initial access, application) |
|
Geographical area |
geographical area |
|
Information to broadcast |
bit string |
The size of the information to broadcast is not bound by this description, but may be constrained by the access system.
The geographical area is used by the AN to determine which access points are concerned. The rules are not specified in the external specification of the AS, but must exist and must be consistent with other translations between geographical descriptions and access points (e.g., in the connection establishment).
The category is used by the AN to determine priority and more generally the parameters governing information repetition over time.
NOTE: The category field could be enhanced, e.g., to allow a more precise control of priorities and repetitions.
6.2.2.1.1.2 Information Broadcast Indication, UE Side
The parameters are:
|
Access point reference |
local |
|
Broadcast information |
bit string |
The access point reference identifies the point on the access boundary (e.g., the cell) where the information was received.
NOTE: The access point reference is a local reference, to be used in other primitives at the AS/NAS boundary in the same UE.
6.2.2.2 Notification SAPs
Notification operations consists of sending information to a dedicated user/terminal, or a group of users/terminals over a defined geographic area.
Typically the request is forwarded to the user/terminal on a broadcast resource. If the AN knows of an existing signalling relation to the user/terminal, the information might be sent through the existing relation, according to Access Stratum specifications.
6.2.2.2.1 Paging Request, IF side
The parameters are the following:
|
User/Terminal Identity |
pageable identity |
|
Geographical area where to broadcast |
geographical area |
|
Paging resource parameters |
paging resource parameters |
|
Information to send |
bit string |
The user/terminal identity is provided to determine if a signalling relation with the user/terminal exists. The geographical area indicates the area in which the Core Network knows the User/Terminal(s) to be.
The size of the information to send is not bound by this description, but may be constrained by the access system.
The paging resource parameters are used to determine which paging resource to be used when several are available. The organisation of paging resources is known in advance by the User Equipment, and are used by the User Equipment to choose the paging resources to listen to. The exact use of the paging resource parameters is specified as part of Access Stratum specifications.
NOTE: This function is typically used for paging, i.e., to trigger an access from the User/Terminal. However, this is not relevant to the Access Stratum, and other uses can be envisaged without impacting the Access Stratum. The action required from the MS, if any, is indicated, implicitly or explicitly, in the information to send, the content of which being part of the Non Access Strata specifications and not of the Access Stratum specifications.
6.2.2.2.2 Notification Broadcast Request, IF side
The parameters are the following:
|
Geographical area where to broadcast |
geographical area |
|
Notification resource parameters |
paging resource parameters |
|
Information to broadcast |
bit string |
The size of the information to broadcast is not bound by this description, but may be constrained by the access system.
The paging resource parameters are used to determine which paging resource to be used when several are available. The organisation of paging resources is known in advance by the User Equipment, and are used by the User Equipment to choose the paging resources to listen to. The exact use of the paging resource parameters is specified as part of Access Stratum specifications.
NOTE: This operation is used typically to inform all MSs of some starting or on-going activities, such as group calls.
6.2.2.2.3 Notification Indication, UE side
Parameters
|
Access point reference |
local |
|
Broadcast information |
bit string |
NOTE: This primitive applies both for a paging sent on broadcast resources and for the reception of an information broadcast to many users.
6.2.2.3 Dedicated Control SAPs
Dedicated Control operations are done within the scope of a connection, embodied by corresponding SAPs on the UE and IF sides. This scope is determined by local references (respectively on the UE side and on the IF side). All operations contain such a local reference, and, at a given AN/CN interconnection point, all operations with the same local reference from the establishment event to the release event pertain to the same connection. The correspondence between Dedicated Control SAPs on the UE and IF side is dynamic, and established through the connection establishment operations.
The local connection references have only a local scope, and their values do not necessarily have any predictable relationship with the corresponding reference local to the other side, or with a reference used over some interface to multiplex the messages pertaining to the connection with messages pertaining to other connections.
6.2.2.3.1 UE Side Initiated Connection Establishment
This operation consists in the establishment of a new connection at the initiative of NAS on the User Equipment side.
6.2.2.3.1.1 UE Side Initiated Connection Establishment Request, UE side
Parameters
|
Local connection reference |
local |
|
Routing parameters |
routing parameters |
|
Initial message |
bit string |
The routing parameters are to be used by the AS on the Infrastructure side to choose the AN/CN connection point through which the connection is to be established.
The initial message is to be forwarded to the non-access strata. The size of the initial message should not be constrained by the access system.
6.2.2.3.1.2 UE Side Initiated Connection Establishment Indication, IF side
Parameters
|
Local connection reference |
local |
|
Initial message |
bit string |
|
Localisation data |
localisation data |
The localisation data indicate the knowledge the AN has of the localisation of the initiating User Equipment. It includes typically a geographical area and some accuracy indication.
6.2.2.3.1.3 UE Side Initiated Connection Establishment Confirm, IF Side
Parameters
|
Local connection reference |
local |
|
Status |
enumerated (terminated by NAS, going on) |
|
Initial answer |
bit string |
The NAS can choose not to pursue the connection (status = terminated by NAS). Reasons can be that the information provided by the User Equipment did not require more than a single message answer (e.g., store-and-forward service), or some exception conditions prevented the CN to pursue the connection.
The initial answer is to be provided to the requesting part in the non-access strata.
6.2.2.3.1.4 UE Side Initiated Connection Establishment Response, UE side
Parameters
|
Local connection reference |
local |
|
Status |
enumerated (terminated by NAS, terminated by AS, going on) |
|
Initial answer |
bit string |
The initial answer is not provided in the case the status is ‘terminated by AS’. The status ‘going on’ and ‘terminated by NAS’ indicates that the initial message was delivered to the NAS; on the other hand, the status ‘terminated by AS’ can happen whether or not the initial message was delivered to the NAS.
6.2.2.3.2 Connection Release
This operation is the termination of a connection, at the request of non-access strata on the Infrastructure side. The use of this operation may lead to the non-completion of other previously started operations in the same connection (e.g., transparent data transfer).
6.2.2.3.2.1 IF Initiated Connection Release Request, IF Side
Parameter
|
Local connection reference |
local |
6.2.2.3.2.2 IF Initiated Connection Release Indication UE side
Parameter
|
Local connection reference |
local |
6.2.2.3.3 Information Transfer
These operations allow the transfer of messages between Non-Access Strata elements on each side of the access interface.
The service is essentially that of a transport layer, with multiplexing, and possibly guarantee of order and correct transmission (transmission difficulties lead to connection loss), including the effect of user movements. The operation caters only for transmission from AS boundary to access boundary. Upper layers of protocol are typically added for addressing and routing beyond this boundary.
Several independent streams can exist simultaneously on the same connection, as distinguished by a routing and transaction identifiers. Message order is guaranteed, if applicable, on a stream basis. Routing identifiers are typically used to indicate originator and destination (e.g., USIM to Home, ME to Serving, and also distinctions such as GSM between MM and CC for instance…). Transaction identifiers are used to distinguish streams with the same originator and destination. Messages can be sent within a transaction or not. Transactions are explicitly set up and released, either in-band (i.e., together with information transfer) or out-band. Transaction identifiers have only a local significance.
NOTE 1: There is a difficulty behind the message order. In some cases it may be important to keep message order in a combination of streams, e.g., within a route, or even involving two routes. The model presented so far is too simple to cope with such cases.
A quality of service indication is present in sending requests. This covers such aspects as message order, effect on other on-going traffic (e.g., speech pre-emption), delay. A finite number of quality of service classes will be identified, and the one to apply to a message indicated.
With each transaction is associated a default quality of service, established at transaction establishment or by a subsequent modification request.
A transmission mode indication is present in reception indications. This gives information from the Access Stratum on the aspects of the transmission related to service quality of service (e.g., speech has been pre-empted).
NOTE 2: This covers circuit data transport, including cases where each message is very small (down to 1 bit or other information quantum). Obviously, in such cases these primitives are a model not to be followed in implementations.
6.2.2.3.3.1 Data Transfer Request, IF Side
Parameters
|
Local connection reference |
local |
|
Route |
route |
|
Transaction identification |
local |
|
Transaction management |
enumerated (single, first, subsequent, last) |
|
Quality of Service indication |
QoS |
|
Message |
bit string |
The transaction management field indicates if the message is independent from transactions (single), is the first of the transaction and hence initialises the transaction (first), is the last of the transaction and hence releases the transaction (last), or is in the middle of a transaction.
The primitive can be used with an empty message for transaction management alone (value ‘single’ is then meaningless).
6.2.2.3.3.2 Data Transfer Indication, UE Side
Parameters
|
Local connection reference |
local |
|
Route |
route |
|
Transaction identification |
local |
|
Transaction management |
enumerated (single, first, subsequent, last) |
|
Transmission mode indication |
transmission mode |
|
Message |
bit string |
6.2.2.3.3.3 Data Transfer Request, UE Side
Parameters
|
Local connection reference |
local |
|
Route |
route |
|
Transaction identification |
local |
|
Transaction management |
enumerated (single, first, subsequent, last) |
|
Quality of Service indication |
QoS |
|
Message |
bit string |
6.2.2.3.3.4 Data Transfer Indication, IF Side
Parameters
|
Local connection reference |
local |
|
Route |
route |
|
Transaction identification |
local |
|
Transaction management |
enumerated (single, first, subsequent, last) |
|
Transmission mode indication |
transmission mode |
|
Message |
bit string |
6.2.2.3.4 IF Side Initiated Radio Access Bearer Establishment
These operations allow the transfer of control messages for radio access bearer establishment between non-access strata elements on each side of the access interface. The operations pertain to the connection identified by the local connection reference parameter. The operations allow the IF side to initialise a radio access bearer. The operation also implies a request to the AS to allocate transmission resources to the radio access bearer.
A radio access bearer identification uniquely identifies the radio access bearer. It is used in all primitives that pertain to the radio access bearer. It also serves as the binding to a NAS call.
The Iu bearer identification identifies the Iu connection.
A quality of service request specifies the bearer characteristics that apply to the radio access bearer.
6.2.2.3.4.1 IF Side Initiated Radio Access Bearer Establishment Request, IF Side
Parameters
|
Local connection reference |
local |
|
Radio access bearer identification |
bit string |
|
Iu bearer identification |
bit string |
|
Quality of Service request |
QoS |
6.2.2.3.4.2 IF Side Initiated Radio Access Bearer Establishment Indication, UE Side
Parameters
|
Local connection reference |
local |
|
Radio access bearer identification |
bit string |
|
Iu bearer identification |
bit string |
6.2.2.3.4.3 IF Side Initiated Radio Access Bearer Establishment Response, UE Side
Parameters
|
Local connection reference |
local |
|
Radio access bearer identification |
bit string |
|
Status |
enumerated (terminated by NAS, going on) |
6.2.2.3.4.4 IF Side Initiated Radio Access Bearer Establishment Confirm, IF Side
Parameters
|
Local connection reference |
local |
|
Radio access bearer identification |
bit string |
|
Status |
enumerated (terminated by NAS, terminated by AS, going on) |
6.2.2.3.5 IF Side Initiated Radio Access Bearer Release
These operations allow the transfer of radio access bearer release messages between non-access strata elements on each side of the access interface. The operations pertain to the connection identified by the local connection reference parameter. The operations allow IF side to release a radio access bearer.
NOTE: A radio access bearer release procedure is normally initiated by the IF side. Abnormal cases such as termination by the AS are FFS.
6.2.2.3.5.1 IF Side Initiated Radio Access Bearer Release Request, IF Side
Parameters
|
Local connection reference |
local |
|
Radio access bearer identification |
bit string |
6.2.2.3.5.2 IF Side Initiated Radio Access Bearer Release Indication, UE Side
Parameters
|
Local connection reference |
local |
|
Radio access bearer identification |
bit string |
6.2.3 IF side only operations
6.2.3.1 Dedicated control SAPs
6.2.3.1.1 Position update indication
Parameters
|
Local connection reference |
local |
|
Position |
position |
6.2.3.1.2 Connection loss indication
Parameters
|
Local connection reference |
local |
6.2.3.1.3 Streamlining required indication
This operation is used by the AS to indicate that the connection runs the risk to be aborted unless a streamlining is done.
Parameters
|
Local connection reference |
local |
|
Proposed list of alternative AN/CN points |
AN/CN point list |
6.2.3.1.4 Branch establishment request
This operation establishes a new branch supporting dedicated mode transport for a given UE.
Parameters
|
Local connection reference |
local |
|
Transaction list |
transaction list |
The transaction list describes the transactions for which the establishment prior the first transmission of data is required.
6.2.3.1.5 Branch establishment confirm
This indicates that the branch is successfully established up to the UE and can then be used for transmission. As a result, the NAS may decide to remove the old branch.
Parameters
|
Local connection reference |
local |
6.2.3.1.6 UE location information request
This operation is sent from the NAS entity inside the CN (i.e. edge node) to the access network side of AS (i.e. URAN) to request the location information of a specific UE.
Parameters:
|
Local connection reference |
local |
|
Level of accuracy |
basic level or advanced level |
|
Type of request |
direct request or event request |
|
Event |
conditions to send information |
The level of accuracy describes the granularity required on the UE location information, either basic or advanced. The type of request describes whether the request is to get the current UE location or to get the location when some conditions specified by event are satisfied.
6.2.3.1.7 UE location information confirm
This operation is sent in response to the UE location information request operation.
Parameters:
|
Local connection reference |
local |
|
Area ID |
UE location information in terms of CGI format |
|
Geographic coordinates |
UE location information in terms of coordinates |
|
Event |
conditions met |
The Area ID is to be formatted in accordance with the CGI (Cell Global Identity). The geographic co-ordinates represents the physical co-ordinates on the earth and uncertainty parameters.
[To be completed]
6.2.4 UE side only operations
6.2.4.1 Dedicated control SAPs
6.2.4.1.1 Connection loss indication
Parameters
|
Local connection reference |
local |
[To be completed]
6.3 Parameters structure
6.3.1 Local
The structure is not relevant in the scope of this document, and can be decided on an implementation basis.
6.3.2 Bit string
A finite ordered sequence of bit values.
6.3.3 Enumerated
The parameter can take one value out of a list explicitly given.
6.3.4 Geographical description
TBI
6.3.5 QoS
This clause describes the radio access bearer (RAB) by referencing a list of attributes related to the QoS. The radio access bearers are divided into two categories:
– Restricted radio access bearers;
– Unrestricted radio access bearers.
An unrestricted radio access bearer is meant for data requiring bit sequence integrity (;e.g., N-ISDN data transport), whereas a restricted radio access bearer contains a description of the nature of the information (;e.g., encoded voice). For a restricted radio access bearer, the characteristics are implicitly given.
The characterisation of a radio access bearer is made by using a set of attributes. A radio access bearer attribute is a specific characteristic that distinguishes it from other radio access bearer services. Refer to TS 23.107 [5] for a list of these QoS attributes. Particular values are also indicated in that specification for different services.
In order to describe the desired radio access bearer service, QoS attributes are defined at the SAP. Note that it is not necessary, nor meaningful to support all possible combinations of parameter settings.
NOTE: In case of an unrestricted radio access bearer, for every SDU provided at the SAP, bit sequence integrity should be maintained.
6.3.6 Route
TBI
6.3.7 Transaction identifier
Local.
6.3.8 Transaction list
A list of transactions, each described by a transaction identifier (local) and by QoS parameters.
6.3.9 Transmission mode
TBI
6.3.10 AN/CN Point List
TBI
6.3.11 Localisation
TBI
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2004-12 |
SA#26 |
Created version 6.0.0 |
5.0.0 |
6.0.0 |
|||
|
2007-06 |
SP-36 |
– |
– |
– |
Updated to Rel-7 version (MCC) |
6.0.0 |
7.0.0 |
|
2008-12 |
SP-42 |
– |
– |
– |
Updated to Rel-8 version (MCC) |
7.0.0 |
8.0.0 |
|
2009-12 |
SP-46 |
– |
– |
– |
Updated to Rel-9 version (MCC) |
8.0.0 |
9.0.0 |
|
2011-03 |
SP-51 |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.0.0 |
10.0.0 |
|
2012-09 |
– |
– |
– |
– |
Update to Rel-11 version (MCC) |
10.0.0 |
11.0.0 |
|
2012-09 |
– |
– |
– |
– |
Update to Rel-11 version (MCC) |
10.0.0 |
11.0.0 |
|
2014-09 |
SP-65 |
– |
– |
– |
Update to Rel-12 version (MCC) |
11.0.0 |
12.0.0 |
|
2015-12 |
– |
– |
– |
– |
Update to Rel-13 version (MCC) |
12.0.0 |
13.0.0 |
|
2017-03 |
– |
– |
– |
– |
Update to Rel-14 version (MCC) |
13.0.0 |
14.0.0 |
|
2018-06 |
SP-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
14.0.0 |
15.0.0 |
|
2020-07 |
SP-88E |
– |
– |
– |
Update to Rel-16 version (MCC) |
15.0.0 |
16.0.0 |
|
2022-03 |
SP-95E |
– |
– |
– |
Update to Rel-17 version (MCC) |
16.0.0 |
17.0.0 |