10 Charging Aspects
22.2783GPPService requirements for the Evolved Packet System (EPS)TS
The Evolved Packet System shall support various charging models including all those supported by the 3GPP system contained within TS22.115 [5] .
Charging models that shall be supported by the Evolved Packet System include (non-exhaustive list):
– calling party pays
– charging based on assured QoS
– charging based on the transport
– charging based on an event
– charging based on content
– charging adjustment (e.g. based on subscription bands)
– alternate party charging
The Evolved Packet System shall also be able to support introduction of new charging schemes including online and offline schemes, and charging schemes for the multi-access system environment
Charging mechanisms of the Evolved Packet System shall provide (non-exhaustive list):
– Cost effective Control and Charging of IP Flows
– Perform online charging
– Support differentiated charging including zero rating of the bearer and event charging
– Awareness of subscriber identity, time-of-day, roaming status, QoS, Service input etc
Annex A (informative):
Requirements for further study
A.1 Management of access networks
The Evolved Packet System shall be able to allow for self-managing technologies (e.g. Plug-and-Play) for dynamically adding and removing non-3GPP defined access networks.
Such self-managing technologies shall take into account the Evolved Packet System and access network policies.
E.g. depending on such policies it shall be possible to for the 3GPP system operator to request encryption of user traffic that is transmitted over the access network.
Note 1: The non-3GPP access network needs to have defined interworking with 3GPP.
An example could be a WLAN (operated by some WLAN operator) that can, if needed, automatically be connected to a PLMN. This would enable the PLMN operator to provide additional access resources on a dynamic basis and to provide service to more customers (e.g. at mass events).
Note 2: The degree of automation provided for network attachment is yet to be determined, but is intended to simplify (or completely automate) administration procedures.
A.2 Use cases for Fixed Mobile Convergence
A family has purchased a family subscription plan that is independent of access (e.g. fixed or wireless) and location (e.g. both when at home and away from home). The subscription contains at least the following components:
- Internet access: Operator specific service such as firewall and content filtering (parental control) independent of access for selected devices within the family. The service should be available at home, within the home mobile network and when roaming to a visited mobile network.
- Voice/Multimedia: QoS and mobility between home WLAN and LTE wide area
- Charging schemas connected to access type, preference and location
- Video: Premium Video on Demand Service incl. guaranteed bandwidth and QoS regardless of access network.
Description
Use case 1: Internet access with Parental control and personal firewall
The kids leave their house and take a bus to their grandparents’ house.
The operator specific services, like parental control and personal firewall, are invoked for specific users and terminals from both fixed network and from mobile network; this allows the kids to get the same service and filtering inside the home, in the bus going to grandparents and at the grandparents. In this use case the grandparents have a separate service provider than the family but the services will still be provided by the service provider where the family has a subscription.
Use case 2: Voice/Multimedia and Charging
The father travels home after work while talking on the phone with his colleague.
The ongoing Voice/Multimedia call between the father and his colleague is maintained while switching over between LTE Wide area and residential fixed broadband WLAN network. Once the call is switched over to WLAN charging for home-based access is applied. Bandwidth and QoS is maintained for the duration of the call to guarantee the same service delivery.
Use case 3: Video
The kids in the backseat of the car are watching an Internet TV show on their laptop using LTE while driving home from the grandparent’s house.
The TV show is sent from an Internet TV provider. Once home the terminal detects indoor WLAN coverage where the subscriber has a WLAN Residential Gateway connected to his Fixed Broadband network. The user or the terminal automatically may select to switch the IP connection to the wireline broadband connection and enable the user to resume watching the same TV show on the same laptop, possibly with a better quality picture as allowed by the available bandwidth, user-specific policy, network policy and QoS setting.
Use case 4: H(e)NB/Femtocell
A subscriber desires to improve coverage and access speed for their 3GPP device in their home. They purchase and install a small eNodeB (Femtocell AP) device for their home which attaches to the home LAN and establishes a connection back to the subscriber’s mobile service provider network. The mobile network provider coordinates with the broadband access provider to deliver proper bandwidth and QoS to support a good QoE for calls and data sessions made within the home that access services from the mobile network. The Femtocell also allows some types of data traffic to be shared with the home LAN, including traffic for Internet applications. Local traffic can be discerned and accounted for differently than traffic that is carried on the mobile network.
Use case 5: Application Mobility
A subscriber is in a multimedia call on their mobile device, and then wishes to change the device they are using to a fixed network attached device (e.g. Set Top Box / TV). The multimedia call is handed over from the mobile network to the fixed network after the subscriber chooses to transfer the multimedia call to a STB / TV. Bandwidth and QoS is maintained for the large screen experience to be meaningful. Accounting and settlement is supported among the application and network service providers, and reflects the changes to the access technology and required bandwidth.
Use case 6: Common Quota
A Common Quota (CQ) can be assigned for both fixed and mobile accesses for a limited time period for a defined set of subscriptions. During each session the network elements monitor the CQ which may be consumed by one or more devices over either the wireless or fixed networks.
When a defined percentage of the CQ and/or all the CQ has been consumed, one or more subscribers in the defined set can be notified of the event (e.g. via SMS and/or email).
When the CQ has been consumed the access to the services is blocked.
Use case 7: Video On Demand Service
Video On Demand (VoD) service is provided to the subscriber via the Set Top Box to the TV or to the PC. A user orders a VoD service interacting with the VoD infrastructure, which sends a resource request to the network. The user may also request mid-session requests triggering the increase/decrease of network resources. The requests will be accepted or rejected according to the available network resources.
Use case 8: Broadband Access Wholesale
In Broadband network the wholesale scenario is quite important as it may be required by the regulation, known as unbundling (access, connectivity and services). For example the operator of the broadband access network lease/sell transport of the connection through its own network from the user to the buyer / leased network. So in the wholesale scenario the renting operator has the end-to-end Service responsibility to the customer and is viewed as the "Retailer" of the service or application. While the leasing network operator has the responsibility for the access network and for the connectivity.
Annex B (Normative):
Void
Annex B1 (Informative): Interworking between Mobile Operators and Data Application Providers
This Annex provides various scenarios and use cases applicable for interworking between mobile operators and data applications.
B1.1 Scenarios
Figure 1 shows the non-roaming scenario where the mobile operator owns the EPS as well as application layer entities. Access and IP connectivity is provided by the mobile operator. Application platforms, also provided by the mobile operator, shown in the figure connect to the core network directly. Application platforms could be application servers (e.g. Video on Demand Server, PSS Server, MTC Server, etc.). Applications developed using APIs (e.g. REST, GSMA OneAPI) and resident on the API Gateway are connected to the operator core network via the API Gateway. The dashed lines between Operator CN and IMS as well as API Gateway are already specified.
Figure 1: Operator owned non-roaming scenario
Figure 2 provides the non-roaming scenario where the mobile operator does not own all the application layer entities. Access and IP connectivity is provided by the mobile operator. The 3rd party Application Platforms in this figure could be application servers (e.g. Video on Demand Server, PSS Server, MTC Server, etc.) or could be 3rd party software development platforms. The horizontal line represents the demarcation between the mobile operator domain and the 3rd party application provider domain. The mobile operator and 3rd party application providers may have agreements.
Figure 2: Collaborative non-roaming scenario
Figure 3 provides the roaming scenario for both the above owned and collaborative scenarios. This figure shows the home-routed scenario where all traffic is routed to home mobile operator EPS and applications are delivered via roaming agreements between mobile operators.
Figure 3: Operator owned/collaborative roaming scenario – Home Routed
Figure 4 provides the roaming scenario between mobile operators and 3rd party application provider domains. In this scenario the application provider has agreements with visited mobile operator. This figure shows the local-breakout scenario where all traffic is routed to application domain from the visited operator network.
Figure 4: Collaborative roaming scenario – Local Breakout
B1.2 Use cases
B1.2.1 Use cases for owned / collaborated scenarios.
Pre-conditions
A data application provider X develops an application customized for streaming high definition movies to the mobile end user over 3GPP access.
The data application provider X develops this application specifically for a mobile network operator (MNO) Y. The data application provider X hosts this application and establishes agreements with a mobile network operator (MNO) Y to pilot the service. Authentication and charging are provided by the MNO Y. The data application provider X can collaborate with other MNOs as well.
Alice has subscribed to a 3GPP device and video services from the MNO Y.
Use case 1: Authentication and Authorization
Alice gets onto a train for 4-hour long ride to a neighboring country. She turns on her device and looks at the movie catalog. She decides to view a movie and selects the movie offered by the data application provider X and watches it without worrying about the radio access network she is using and any additional login/password procedures.
Use case 2: Allocation of resources and other policy interactions
All along the MNO Y manages the resources and the QoS needed for high definition movie streaming to Alice. On the train, Alice gets distracted by the scenery and misses a few scenes. She rewinds and views the missing scenes.
Use case 3: Simultaneous interactions with multiple application providers
Alice comes across an interesting gadget in the movie and decides to pause on that scene and get a higher resolution closeup view. The close up view prompts an advertisement to pop up for the gadget. Based on this advertisement, Alice purchases the gadget. She is given the choice of paying immediately or being charged on her MNO monthly bill. She decides to charge to her MNO bill.
Use case 4: Roaming
Alice continues watching the movie and the train crosses the country border. She starts roaming into another MNO Z, which has roaming agreement with MNO Y. The movie quality is unaltered in the process of roaming.
Use case 5: Charging
She gets a bill from the MNO at the end of the month which includes the price for the movie she watched on the train and the gadget she purchased.
B1.2.2 Use cases for non-collaborated scenarios.
B1.2.2.1 UE initiates and requests MNO for preferential traffic handling
Pre-conditions
1. Mobile Network Operator Y (MNO Y) has no business relationship nor is there any service collaboration with Data Application Provider X (DAP X).
2. DAP X develops a free application customized for streaming movies to the mobile end user over 3GPP access. DAP X develops the application independently from MNO Y and hosts this application outside of MNO Y’s network. The user accesses the service via the network of MNO Y connected to DAP X via a transit network. The service is provided to the user transparently through MNO Y’s network.
3. The network of MNO Y supports tiered bearers and MNO Y offers prefential traffic handling on demand from users with a preview period defined either by the operator or the application provider for acceptance of the service. MNO Y has a roaming agreement with MNO Z to provide preferential traffic handling for users at an extra cost to the user. MNO Y has no knowledge or control of the service being delivered by DAP X. Further MNO Y has no knowledge of the resources available at DAP X or of those in the transit network through which it is connected.
4. Alice has subscribed to a 3GPP data service from MNO Y and has downloaded the free movie streaming application from DAP X. She has purchased credit through the application to enable streaming of content. No further authentication of authorisation is required with DAP X in order for Alice to receive content. The movie streaming application uses default level of resources and QoS (e.g. best effort, or based the subscriber profile) from the PLMN.
5. Alice is on a train travelling across national boarder from Country A to Country B. Country A is served by MNO Y. Country B is served by MNO Z.
Use case 6: Authentication and Authorization
Alice decides to watch a movie. She turns on her device, registers with the network operated by MNO Y and launches the application to browse the movie catalogue. She decides to view a movie so she selects it and starts to watch it.
Use case 7: Allocation of resources and other policy interactions
At some point in the movie (e.g. due to mobility, network congestion, etc) Alice becomes dissatisfied with the quality of the movie.
Alice requests preferential traffic handling from MNO Y.
Alternative 1. Alice does not notice any improvement in the quality of the streamed movieand she does not confirm the request for preferential traffic handling within the preview period.
Alternative 2. Alice notices a marked improvement in the quality of the streamed movie and she confirms the request for preferential traffic handling.
As the train crosses the national boarder between Country A and Country B, Alice is notified of the change in MNO and charging.
Alternative 3. Alice decides not to consent for the additional charge. The quality of the bearer reverts to its default level after the specified consent period has expired.
Alternative 4. Alice decides to pay additional charge and consents. The quality of the bearer remains at its present level.
Use case 8: Charging
Alternative 1. Alice receives a bill from MNO Y at the end of the month that includes roaming charges from MNO Z, but no additional charges for preferential traffic handling.
Alternative 2 + Alternative 3. Alice receives a bill from MNO Y at the end of the month that includes roaming charges from MNO Z, and the cost for preferential traffic handling from MNO Y.
Alternative 2 + Alternative 4. Alice receives a bill from MNO Y at the end of the month that includes roaming charges from MNO Z, as well as the cost for preferential traffic handling from MNO Y and the additional cost for preferential traffic handling from MNO Z.
Alice does not receive any bill from DAP X related to the request for preferential traffic handling.
B1.2.2.2 UE initiates and Data Application Provider requests MNO for preferential traffic handling
Pre-conditions
1. Mobile Network Operator Y (MNO Y) has a business relationship but no service collaboration with Data Application Provider X (DAP X).
Other pre-conditions are as specified for B1.2.2.1
Authentication and Authorization is as per Use Case 6 in B1.2.2.1
Use case 9: Allocation of resources and other policy interactions
At some point in the movie (e.g. due to mobility, network congestion, etc) Alice becomes dissatisfied with the quality of the movie. Alice requests preferential traffic handling from DAP X.
Alternatives 1 to are as described in Use case 2 under B1.2.X.
Use case 10: Charging
Alternative 1. Alice receives a bill from MNO Y at the end of the month that includes roaming charges from MNO Z.
Alternative 2 + Alternative 3. Alice receives her bill from MNO Y at the end of the month that includes roaming charges from MNO Z. In addition, Alice receives a statement from DAP X which includes an entry for the cost of preferential traffic handling from MNO Y.
Alternative 2 + Alternative 4. Alice receives her normal bill from MNO Y at the end of the month including roaming charges from MNO Z. In addition, Alice receives a statement from DAP X which includes an entry for the cost of preferential traffic handling from MNO Y and MNO Z.
Annex B2 (Informative): Service Reachability
B2.1 Use case: Blocking Service Reachability
B2.1.1 Description
This describes a case where the intention of the firewall provider is to ensure all traffic of a specific type, e.g. VoIP, is blocked even though the network operator and UE uses Service Reachability.
B2.1.2 Pre-conditions
– The network operator provides a VoIP service.
– The user is subscribed to the VoIP service.
– The UE is connected to a firewalled WLAN network that is independent from the network operator.
– The firewall of the WLAN network blocks VoIP traffic as a result of the firewall provider policy.
– The UE and network operator implements Service Reachability.
– The firewall provider blocks Service Reachability.
– The network operator and firewall provider are different entities.
– This scenario applies regardless of whether there is a business relationship between the network operator and the firewall provider.
B2.1.3 Service Flow
a) The user attempts to make a voice call using the network operator VoIP service.
b) The firewall blocks the VoIP call.
c) The UE then uses the Service Reachability functionality to initiate the call.
d) The firewall blocks the Service Reachability function.
B2.1.4 Post-conditions
– User VoIP call attempt fails.
– The firewall provider policy to block VoIP traffic is maintained.
Annex C (informative):
Change history
|
Change history |
|||||||||||
|
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
WI |
|
SP-35 |
SP-070128 |
S1-070187 |
22.278 |
0001 |
2 |
Rel-8 |
F |
Clarification on QoS classes for evolved 3GPP system |
8.0.0 |
8.1.0 |
SAE-R |
|
SP-35 |
SP-070127 |
S1-070197 |
22.278 |
0002 |
– |
Rel-8 |
B |
Provision of access network information to the UE |
8.0.0 |
8.1.0 |
SAE-R |
|
SP-36 |
SP-070365 |
S1-070806 |
22.278 |
0003 |
3 |
Rel-8 |
B |
Requirement for handovers between LTE and 3GPP2 access networks |
8.1.0 |
8.2.0 |
SAE-R |
|
SP-36 |
SP-070369 |
S1-070556 |
22.278 |
0005 |
Rel-8 |
D |
Editorial correction for performance requirements for evolved 3GPP system |
8.1.0 |
8.2.0 |
SAE-R |
|
|
SP-36 |
SP-070367 |
S1-070807 |
22.278 |
0006 |
1 |
Rel-8 |
B |
Performance requirements for evolved 3GPP system |
8.1.0 |
8.2.0 |
SAE-R |
|
SP-36 |
SP-070370 |
S1-070764 |
22.278 |
0008 |
1 |
Rel-8 |
B |
Requirement for national roaming between LTE-only operators and 2G/3G-only operators |
8.1.0 |
8.2.0 |
SAE-R |
|
SP-36 |
SP-070483 |
S1-070805 |
22.278 |
0009 |
5 |
Rel-8 |
B |
Requirements for service continuity between 3GPP system and WiMAX |
8.1.0 |
8.2.0 |
SAE-R |
|
SP-37 |
SP-070566 |
S1-071324 |
22.278 |
10 |
2 |
Rel-8 |
D |
Addition of 3GPP reference for the evolved 3GPP packet system (EPS) |
8.2.0 |
8.3.0 |
SAE-R |
|
SP-37 |
SP-070566 |
S1-071096 |
22.278 |
11 |
1 |
Rel-8 |
B |
Multiple IP session |
8.2.0 |
8.3.0 |
SAE-R |
|
SP-37 |
SP-070566 |
S1-071097 |
22.278 |
12 |
1 |
Rel-8 |
B |
Voice service continuity between 3GPP RAT and non 3GPP RAT |
8.2.0 |
8.3.0 |
SAE-R |
|
SP-37 |
SP-070566 |
S1-070994 |
22.278 |
13 |
1 |
Rel-8 |
B |
Alignment of terminology with SA2 |
8.2.0 |
8.3.0 |
SAE-R |
|
SP-37 |
SP-070566 |
S1-071122 |
22.278 |
14 |
1 |
Rel-8 |
B |
Access network discovery |
8.2.0 |
8.3.0 |
SAE-R |
|
SP-38 |
SP-070855 |
S1-071856 |
22.278 |
0021 |
2 |
Rel-8 |
C |
Support for efficient delivery of text-based broadcast messages |
8.3.0 |
8.4.0 |
AIPN-SAE |
|
SP-38 |
SP-070855 |
S1-071912 |
22.278 |
0022 |
1 |
Rel-8 |
B |
Emergency Call Support |
8.3.0 |
8.4.0 |
AIPN-SAE |
|
SP-38 |
SP-070856 |
S1-071913 |
22.278 |
0015 |
3 |
Rel-8 |
B |
Enhancements to Access network discovery and steering of access |
8.3.0 |
8.4.0 |
AIPN-SAE |
|
SP-38 |
SP-070856 |
S1-071915 |
22.278 |
0017 |
1 |
Rel-8 |
F |
Multi-access MBMS |
8.3.0 |
8.4.0 |
SAE-R |
|
SP-38 |
SP-070856 |
S1-071916 |
22.278 |
0018 |
1 |
Rel-8 |
B |
QoS change requirement clarification |
8.3.0 |
8.4.0 |
SAE-R |
|
SP-38 |
SP-070929 |
– |
22.278 |
0024 |
2 |
Rel-8 |
C |
Addition of list of applicable specifications for the EPS and amended scope |
8.3.0 |
8.4.0 |
AIPN-SAE |
|
SP-40 |
SP-080306 |
S1-080740 |
22.278 |
0028 |
2 |
Rel-8 |
F |
Clarification of EPS access using pre-Rel-8 USIMs |
8.4.0 |
9.0.0 |
AIPN-SAE |
|
SP-40 |
SP-080306 |
S1-080720 |
22.278 |
0030 |
1 |
Rel-8 |
F |
WIMAX Forum specification reference in TS 22.278 |
8.4.0 |
9.0.0 |
AIPN-SAE |
|
SP-40 |
– |
Creation of v.9.0.0. Content identical to 8.4.0 + CRs 28r2 and 30r1 (but not including CR 27r1, applicable to Rel-8 only, to remove Features which Stage 3 was not completed on time) |
8.4.0 |
9.0.0 |
– |
||||||
|
SP-41 |
SP-080495 |
S1-082018 |
22.278 |
0037 |
– |
Rel-9 |
A |
Service continuity (mirror to a Rel-8 CR) |
9.0.0 |
9.1.0 |
AIPN-SAE |
|
SP-41 |
SP-080639 |
– |
22.278 |
0039 |
3 |
Rel-9 |
A |
Access Network Discovery and Steering of Access |
9.0.0 |
9.1.0 |
AIPN-SAE |
|
SP-41 |
SP-080495 |
S1-082398 |
22.278 |
0041 |
2 |
Rel-9 |
A |
Update IP session control and local breakout requirements |
9.0.0 |
9.1.0 |
AIPN-SAE |
|
SP-41 |
SP-080495 |
S1-082386 |
22.278 |
0043 |
3 |
Rel-9 |
A |
Requirement on support of CS Fallback |
9.0.0 |
9.1.0 |
AIPN-SAE |
|
SP-41 |
SP-080652 |
– |
22.278 |
0043 |
5 |
Rel-9 |
A |
De-implementation of CR43r3 and implementation of 43r5, as approved during SA#41 |
9.1.0 |
9.1.1 |
AIPN-SAE |
|
SP-42 |
SP-080774 |
S1-083114 |
22.278 |
0045 |
– |
Rel-9 |
A |
Deletion of redundant reference |
9.1.1 |
9.2.0 |
AIPN-SAE |
|
SP-42 |
SP-080783 |
S1-083465 |
22.278 |
0049 |
2 |
Rel-9 |
B |
Terminal Identification of 3GPP and 3GPP2 devices |
9.1.1 |
9.2.0 |
TEI9 |
|
SP-42 |
SP-080778 |
S1-084334 |
22.278 |
0051 |
1 |
Rel-9 |
B |
Support for Multimedia Priority Service in EPS |
9.1.1 |
9.2.0 |
AIPN-SAE |
|
SP-42 |
SP-080783 |
S1-084368 |
22.278 |
0054 |
1 |
Rel-9 |
C |
EPS operational deployment and mobility optimization |
9.1.1 |
9.2.0 |
TEI9 |
|
SP-42 |
SP-080783 |
S1-084069 |
22.278 |
0055 |
– |
Rel-9 |
B |
Removal of chapter 6.1.2 and 6.1.3 |
9.1.1 |
9.2.0 |
TEI9 |
|
SP-42 |
SP-080783 |
S1-084425 |
22.278 |
0056 |
3 |
Rel-9 |
D |
Enhanced ANDSF Requirements |
9.1.1 |
9.2.0 |
TEI9 |
|
SP-42 |
SP-080783 |
S1-084414 |
22.278 |
0057 |
1 |
Rel-9 |
C |
Basic support for multiaccess |
9.1.1 |
9.2.0 |
TEI9 |
|
SP-42 |
SP-080783 |
S1-084363 |
22.278 |
0058 |
1 |
Rel-9 |
B |
Adding an appendix with FMC uses cases to 22.278 |
9.1.1 |
9.2.0 |
TEI9 |
|
SP-44 |
SP-090417 |
S1-091153rev |
22.278 |
0062 |
2 |
Rel-9 |
A |
Access Technology Selection across PLMNs |
9.2.0 |
9.3.0 |
SAES |
|
SP-44 |
SP-090371 |
S1-091169 |
22.278 |
0066 |
– |
Rel-9 |
A |
Move sentence about non-3GPP access |
9.2.0 |
9.3.0 |
SAES |
|
SP-44 |
SP-090371 |
S1-091352 |
22.278 |
0067 |
– |
Rel-9 |
A |
Frequency of Scanning for Different Access Technologies |
9.2.0 |
9.3.0 |
SAES |
|
SP-45 |
SP-090476 |
S1-093272 |
22.278 |
0060 |
4 |
Rel-9 |
A |
Alignment about accepting/rejecting CSFB |
9.3.0 |
9.4.0 |
AIPN-SAE |
|
SP-46 |
SP-090843 |
S1-094500 |
22.278 |
0070 |
2 |
Rel-9 |
F |
One active policy ruleset in ANDSF |
9.4.0 |
9.5.0 |
eANDSF |
|
SP-46 |
SP-090904 |
– |
22.278 |
0071 |
7 |
Rel-10 |
B |
Adding of IFOM Requirements |
9.5.0 |
10.0.0 |
IFOM |
|
SP-47 |
SP-100185 |
S1-100236 |
22.278 |
0080 |
5 |
Rel-10 |
B |
Requirements for Fixed Mobile Interworking |
10.0.0 |
10.1.0 |
BBAI |
|
SP-49 |
SP-100575 |
S1-102056 |
22.278 |
0089 |
– |
Rel-10 |
A |
Removal of references to 3GPP OSA |
10.1.0 |
10.2.0 |
TEI10 |
|
SP-49 |
SP-100582 |
S1-102032 |
22.278 |
0083 |
– |
Rel-11 |
B |
Adding a H(e)NB use case to FMC use cases |
10.1.0 |
11.0.0 |
BBAI |
|
SP-49 |
SP-100582 |
S1-102303 |
22.278 |
0084 |
1 |
Rel-11 |
B |
Adding a Application Mobility use case to FMC use cases |
10.1.0 |
11.0.0 |
BBAI |
|
SP-49 |
SP-100582 |
S1-102307 |
22.278 |
0086 |
1 |
Rel-11 |
D |
Clarifications on FMC use cases |
10.1.0 |
11.0.0 |
BBAI |
|
SP-49 |
SP-100582 |
S1-102308 |
22.278 |
0085 |
2 |
Rel-11 |
B |
Adding a Common Quota use case to FMC use cases |
10.1.0 |
11.0.0 |
BBAI |
|
SP-49 |
SP-100582 |
S1-102309 |
22.278 |
0087 |
2 |
Rel-11 |
B |
New Requirements for Fixed Mobile Convergence scenario |
10.1.0 |
11.0.0 |
BBAI |
|
SP-50 |
SP-100802 |
S1-103263 |
22.278 |
0090 |
1 |
Rel-11 |
F |
Clarifying the scenarios supported by FMC interworking, including building block II |
11.0.0 |
11.1.0 |
BBAI |
|
SP-50 |
SP-100802 |
S1-103266 |
22.278 |
0091 |
2 |
Rel-11 |
B |
New Requirements for Enterprise Interworking scenario |
11.0.0 |
11.1.0 |
BBAI |
|
SP-50 |
SP-100802 |
S1-103242 |
22.278 |
0093 |
3 |
Rel-11 |
B |
3GPP EPC based FMC |
11.0.0 |
11.1.0 |
BBAI |
|
SP-50 |
SP-100802 |
S1-103321 |
22.278 |
0095 |
1 |
Rel-11 |
B |
Use cases for BBAI Building Block 3 – Converged scenario |
11.0.0 |
11.1.0 |
BBAI |
|
SP-50 |
SP-100802 |
S1-103323 |
22.278 |
0097 |
– |
Rel-11 |
B |
Evolved Packet Core support for fixed access |
11.0.0 |
11.1.0 |
BBAI |
|
– |
LTE logo changed into LTE Advanced logo |
11.1.0 |
11.1.1 |
– |
|||||||
|
SP-51 |
SP-110165 |
S1-110297 |
22.278 |
0094 |
2 |
Rel-11 |
B |
Scenarios for Interworking between Mobile Operators and Application Providers |
11.1.0 |
11.2.0 |
MOSAP |
|
SP-51 |
SP-110165 |
S1-110404 |
22.278 |
0098 |
3 |
Rel-11 |
B |
New requirements for MOSAP |
11.1.0 |
11.2.0 |
MOSAP |
|
SP-51 |
SP-110165 |
S1-110302 |
22.278 |
0100 |
2 |
Rel-11 |
B |
Use cases for MOSAP |
11.1.0 |
11.2.0 |
MOSAP |
|
SP-51 |
SP-110169 |
S1-110181 |
22.278 |
0099 |
2 |
Rel-11 |
B |
Fixed Broadband Access Network Requirements for BBAI Building Block 3 – Convergent scenario |
11.1.0 |
11.2.0 |
BBAI |
|
SP-52 |
SP-110372 |
S1-111223 |
22.278 |
0101 |
2 |
Rel-11 |
B |
User consent-based charging use case for MOSAP |
11.2.0 |
11.3.0 |
MOSAP |
|
SP-52 |
SP-110372 |
S1-111412 |
22.278 |
0103 |
2 |
Rel-11 |
B |
Non-collaboration requirements for MOSAP |
11.2.0 |
11.3.0 |
MOSAP |
|
SP-53 |
SP-110575 |
S1-112357 |
22.278 |
0110 |
3 |
Rel-11 |
F |
MOSAP – Roaming LBO Architecture Correction |
11.3.0 |
11.4.0 |
MOSAP |
|
SP-54 |
SP-110883 |
S1-113264r |
22.278 |
0106 |
3 |
Rel-12 |
B |
End User Service Reachability via Non-3GPP Access Technologies |
11.4.0 |
12.0.0 |
SMURFs |
|
SP-56 |
SP-120295 |
S1-121406 |
22.278 |
0113 |
2 |
Rel-12 |
B |
Mechanism to block Service Reachability |
12.0.0 |
12.1.0 |
SMURFs |
|
SP-59 |
SP-130116 |
S1-131308 |
22.278 |
0120 |
7 |
Rel-12 |
B |
Incorporation of ProSe Security, Authorization & Privacy Requirements |
12.1.0 |
12.2.0 |
ProSe |
|
SP-59 |
SP-130116 |
S1-131310 |
22.278 |
0121 |
3 |
Rel-12 |
B |
Add WLAN assisted communication requirements |
12.1.0 |
12.2.0 |
ProSe |
|
SP-59 |
SP-130116 |
S1-131319 |
22.278 |
0122 |
6 |
Rel-12 |
B |
Add definitions and abbreviations |
12.1.0 |
12.2.0 |
ProSe |
|
SP-59 |
SP-130116 |
S1-131307 |
22.278 |
0123 |
2 |
Rel-12 |
B |
General Requirements for Proximity Services |
12.1.0 |
12.2.0 |
ProSe |
|
SP-59 |
SP-130116 |
S1-131309 |
22.278 |
0124 |
1 |
Rel-12 |
B |
Public Safety Specific Requirements for Proximity Services |
12.1.0 |
12.2.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132025 |
22.278 |
0133 |
1 |
Rel-12 |
F |
Explicitly excluding GSM and UMTS from ProSe |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132140 |
22.278 |
0150 |
3 |
Rel-12 |
F |
Replace WiFi Direct with WLAN direct communications |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132145 |
22.278 |
0143 |
2 |
Rel-12 |
F |
Clarify what means off network ProSe |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132146 |
22.278 |
0140 |
2 |
Rel-12 |
F |
Deleting a duplicate Public Safety requirement arising from the ProSe Group use case |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132150 |
22.278 |
0128 |
3 |
Rel-12 |
F |
Addition of an agreed requirement in the Public Safety Specific Requirements for Proximity Services |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132153 |
22.278 |
0152 |
2 |
Rel-12 |
F |
Correcting Service Continuity Requirement in UE-to-Network Relay Scenarios |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132165 |
22.278 |
0153 |
4 |
Rel-12 |
F |
Infrastructure path corrections |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132166 |
22.278 |
0156 |
2 |
Rel-12 |
F |
Clarification to interactions between ProSe relaying, ProSe Communication and ProSe Group Communication |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132169 |
22.278 |
0148 |
4 |
Rel-12 |
D |
Clarifying the Requirement on Authorizing ProSe Data Sessions in Public Safety Scenarios |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-132193 |
22.278 |
0131 |
4 |
Rel-12 |
B |
Addition of a new requirement in the Public Safety Specific Requirements for Proximity Services for the use of direct radio signals |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133021 |
22.278 |
0163 |
1 |
Rel-12 |
B |
Add requirement to limit the number of ProSe UE-to-UE relays between two Public Safety ProSe-enabled UEs to one. |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133112 |
22.278 |
0158 |
3 |
Rel-12 |
F |
Addressing uncertainties in deployment of Public Safety ProSe |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133113 |
22.278 |
0132 |
4 |
Rel-12 |
F |
Correction of "in / out of E-UTRAN coverage" and editorials |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133157 |
22.278 |
0172 |
3 |
Rel-12 |
F |
ProSe System means ProSe |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133245 |
22.278 |
0181 |
1 |
Rel-12 |
F |
Correction of ProSe Services to ProSe |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133247 |
22.278 |
0168 |
2 |
Rel-12 |
F |
Update to Requirement on EPC Proximity Detection |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133249 |
22.278 |
0182 |
3 |
Rel-12 |
F |
Setting Up and Handling for ProSe UE-to-UE Relay |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133252 |
22.278 |
0165 |
3 |
Rel-12 |
F |
ProSe Discovery Definition Update |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133257 |
22.278 |
0173 |
2 |
Rel-12 |
F |
Control of resource applies also when UEs are served by the same eNB. |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133259 |
22.278 |
0155 |
3 |
Rel-12 |
F |
On dimensioning requirements for ProSe UE-to-UE Relay |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133267 |
22.278 |
0159 |
3 |
Rel-12 |
F |
Clarifying the Requirement on Pre-Configuring Public Safety ProSe-enabled UEs for operations without any connection to the E-UTRAN. [PR.59-2] (Use Case 5.2.5) |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133272 |
22.278 |
0183 |
5 |
Rel-12 |
F |
Clarification for the use of ProSe UE-to-Network Relay – Network Reachability Indication by ProSe-enabled Public Safety UE Served by E-UTRAN |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133295 |
22.278 |
0169 |
4 |
Rel-12 |
F |
Discovery can be requested by any application |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133296 |
22.278 |
0126 |
2 |
Rel-12 |
F |
Add a ProSe API requirement and two requirement fixes for Proximity Services |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133297 |
22.278 |
0175 |
4 |
Rel-12 |
F |
Remaining details in consistent usage of range terminology |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133299 |
22.278 |
0146 |
8 |
Rel-12 |
F |
Service description for ProSe Discovery and ProSe Communication |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133301 |
22.278 |
0136 |
2 |
Rel-12 |
F |
Clarifying the use of the term "range" |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133310 |
22.278 |
0127 |
9 |
Rel-12 |
F |
Broadening of ProSe Communication Definition to include ProSe Group and ProSe Broadcast Communications for Public Safety. |
12.2.0 |
12.3.0 |
ProSe |
|
SP-60 |
SP-130315 |
S1-133311 |
22.278 |
0176 |
4 |
Rel-12 |
F |
The addition of a definition for "communication range" |
12.2.0 |
12.3.0 |
ProSe |
|
SP-61 |
SP-130412 |
S1-134013 |
22.278 |
0186 |
– |
Rel-12 |
D |
Removing duplicate ProSe definitions |
12.3.0 |
12.4.0 |
ProSe |
|
SP-61 |
SP-130412 |
S1-134144 |
22.278 |
0187 |
1 |
Rel-12 |
F |
Clarification on the ProSe Communication part in ProSe Feature description |
12.3.0 |
12.4.0 |
ProSe |
|
SP-61 |
SP-130412 |
S1-134145 |
22.278 |
0188 |
1 |
Rel-12 |
F |
Clarification on the agreed wording on "concurrent" or "concurrently" in ProSe |
12.3.0 |
12.4.0 |
ProSe |
|
SP-61 |
SP-130412 |
S1-134170 |
22.278 |
0189 |
1 |
Rel-12 |
F |
Clarify requirements for ProSe Security in Public Safety applications. |
12.3.0 |
12.4.0 |
ProSe |
|
SP-64 |
SP-140236 |
S1-141576 |
22.278 |
0201 |
2 |
Rel-13 |
B |
Differential paging for voice over E-UTRAN vs. other services using the IMS signalling bearer |
12.4.0 |
13.0.0 |
voE-UTRAN_PPD |
|
SP-65 |
SP-140523 |
S1-143486 |
22.278 |
0210 |
1 |
Rel-13 |
A |
I-WLAN clean up |
13.0.0 |
13.1.0 |
TEI12 |
|
SP-66 |
SP-140749 |
S1-144429 |
22.278 |
215 |
– |
Rel-13 |
F |
Interference during ProSe Operation in Limited Service state |
13.1.0 |
13.2.0 |
ProSe |
|
SP-72 |
SP-160352 |
S1-161315 |
22.278 |
228 |
1 |
Rel-13 |
F |
Removal of list of EPS Applicable Specifications |
13.2.0 |
13.3.0 |
TEI13 |
|
SP-72 |
SP-160362 |
S1-161602 |
22.278 |
227 |
4 |
Rel-14 |
B |
Requirements for relay UE selection for remote UE access via relay UE |
13.3.0 |
14.0.0 |
REAR |
|
SP-72 |
SP-160362 |
S1-161603 |
22.278 |
225 |
7 |
Rel-14 |
B |
Requirements for Indirect 3GPP Communication |
13.3.0 |
14.0.0 |
REAR |
|
SP-73 |
SP-160539 |
S1-162058 |
22.278 |
0230 |
|
Rel-14 |
A |
Removal of incorrect reference in scope |
14.0.0 |
14.1.0 |
TEI14 |
|
SP-74 |
SP-160895 |
0231 |
3 |
F |
Clarification on REAR |
14.1.0 |
14.2.0 |
||||
|
SP-74 |
SP-160901 |
0232 |
2 |
B |
Inclusion of WLAN direct discovery technologies as an alternative for ProSe direct discovery |
14.1.0 |
15.0.0 |
ProSe_WLAN_DD |
|||
|
SP-170153 |
0236 |
|
A |
Removal of CS Fallback support for Evolved ProSe Remote UE |
15.0.0 |
15.1.0 |
|||||
|
SP-75 |
SP-170153 |
S1-171439 |
22.278 |
0237 |
1 |
Rel-15 |
A |
Relay selection criteria |
15.0.0 |
15.1.0 |
REAR |
|
SP-79 |
SP-180129 |
0240 |
1 |
F |
Clarification of Option 3 core network requirements |
15.1.0 |
15.2.0 |
||||
|
SP-79 |
SP-180129 |
0239 |
4 |
F |
Release 15 alignment on the performance requirements |
15.1.0 |
15.2.0 |
||||
|
SP-79 |
– |
– |
MCC corrected " as specified in TR 38.913" into "as described in TR 38.913". |
15.1.0 |
15.2.0 |
||||||
|
SP-180304 |
0247 |
2 |
F |
Release 15 further alignment on URLLC KPIs |
15.2.0 |
15.3.0 |
|||||
|
SP-180323 |
0245 |
3 |
F |
Support of streaming services |
15.3.0 |
16.0.0 |
eLSTR |
||||
|
SP-81 |
SP-180750 |
S1-182631 |
22.278 |
0264 |
|
Rel-16 |
A |
Inclusion of the CIoT requirements |
16.0.0 |
16.1.0 |
TEI13 |
|
SP-81 |
SP-180758 |
S1-182688 |
22.278 |
0259 |
2 |
Rel-16 |
B |
Inclusion of the 5G requirements — Service continuity |
16.0.0 |
16.1.0 |
SMARTER_Ph2 |
|
SP-81 |
SP-180758 |
S1-182689 |
22.278 |
0263 |
2 |
Rel-16 |
B |
Inclusion of the 5G requirements — Context aware network |
16.0.0 |
16.1.0 |
SMARTER_Ph2 |
|
SP-81 |
SP-180766 |
S1-182759 |
22.278 |
0255 |
4 |
Rel-16 |
F |
Requirement for Operator controlled Caching service delivery |
16.0.0 |
16.1.0 |
eLSTR |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2019-03 |
SA#83 |
SP-190080 |
0266 |
|
F |
Alignment of URLLC requirements |
16.2.0 |
|
2019-09 |
SA#85 |
SP-190924 |
0269 |
7 |
B |
Support for Multi-USIM Devices |
16.3.0 |
|
2019-12 |
SA#86 |
SP-191026 |
0271 |
1 |
F |
Description for supporting MUSIM UE |
17.1.0 |
|
2019-12 |
SA#86 |
SP-191026 |
0272 |
3 |
B |
Add service requirements to support MUSIM UE |
17.1.0 |
|
2021-03 |
SA#91e |
SP-210196 |
0287 |
1 |
A |
Update of requirement for switching of user traffic |
17.2.0 |