100% found this document useful (2 votes)

588 views81 pages

IMS VoLTE Converged Cloud RFP Model - Unanswered - v1 - Jan2020

Uploaded by

Michele Venne

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

100% found this document useful (2 votes)

588 views81 pages

IMS VoLTE Converged Cloud RFP Model - Unanswered - v1 - Jan2020

Uploaded by

Michele Venne

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 81

IMS Model RFP

Table of Contents
1. System Architecture.............................................................4
1.1 VoLTE architecture................................................................................4
1.2 Specifications support...........................................................................4
1.3 Access support......................................................................................4
1.4 IMS Service support..............................................................................5
1.5 Inter-operability......................................................................................5

2. IP Multimedia Subsystem (IMS) Network Elements.............6

2.1 SBC Functional Requirements..............................................................6
2.2 CSCF Functional Requirements..........................................................12
2.3 HSS Functional Requirements............................................................17
2.4 ENUM Functional Requirements.........................................................23
2.5 Application Server Functional Requirements......................................26
2.6 MRF Functional Requirements............................................................43

3. Cloud Infrastructure Solution..............................................47

3.1 VIM requirements................................................................................47
3.2 VNFM requirements............................................................................47
3.3 Hardware.............................................................................................48

4. Regularity Requirements....................................................50
4.1 Emergency Call Handling....................................................................50
4.2 Lawful Interception...............................................................................51

5. Network Management System Solution..............................53

5.1 General Requirement..........................................................................53

About Nokia
Nokia invests in technologies important in a world where billions of devices are connected. We are
focused on three businesses: network infrastructure software, hardware and services, which we
offer through Nokia Networks; location intelligence, which we provide through HERE; and advanced
technology development and licensing, which we pursue through Nokia Technologies. Each of these
businesses is a leader in its respective field.

Nokia is the world’s specialist in mobile broadband. From the first ever call on GSM, to the first call
on LTE, we operate at the forefront of each generation of mobile technology. Our global experts
invent the new capabilities our customers need in their networks. We provide the world’s most
efficient mobile networks, the intelligence to maximize the value of those networks, and the services
to make it all work seamlessly. http://company.nokia.com
5.2 Fault Management...............................................................................54
5.3 Configuration Management.................................................................56
5.4 Performance Management..................................................................56
5.5 Security Management..........................................................................58
5.6 Software Management........................................................................60
5.7 Inventory Management........................................................................60
5.8 User Interface......................................................................................60
5.9 Resilience and Disaster Recovery......................................................61
5.10 Logging................................................................................................61
5.11 Backup and Recovery.........................................................................62
5.12 System Scalability................................................................................62
5.13 Solution Roadmap...............................................................................62
5.14 Interfaces and Protocols......................................................................62
5.15 Documentations...................................................................................63

6. References.........................................................................64
6.1 VoLTE reference..................................................................................64

4. Please highlight the key advantages and benefits of Supplier’s VoLTE solution.

5. Specifications support
6. VoLTE Solution components shall comply with the following latest specifications for the
various standards mentioned below -

 3GPP Release
 IETF RFC
 GSMA VoLTE

7. Access support
8. Supplier must include support for the various access networks for its IMS solution.
Specifically, the following types of access networks are required to be supported.

 UTRAN (UMTS)
 GSM
 WLAN
 DSL
 LTE

11. The supplier shall state for each component of his solution, the compatibility regarding
IPv4/IPv6 at transport level and/or application level, including O&M interfaces.

12. The proposed system must provide all VoLTE supplementary services of GSMA by
invocation of the Application server.

13. Inter-operability
14. Describe the Inter-operability capabilities of the IMS components in a multi-vendor
environment

19. The P-CSCF must support integrity protection on access network for Digest authentication
and key agreement.

20. The P-CSCF shall support Offline Charging using the Rf-interface on the P-CSCF. This is
required for sessions (e.g. voice calls) and events (e.g. SIP based Instant Messages). The
P-CSCF shall be able to generate CDRs according to the version of the 3GPP standards.

21. The P-CSCF shall support SIP signaling compression as specified in IETF RFCs 3321 and
3486.

22. The P-CSCF should support SIP Message Manipulation to support NON-standard UE/IMS
clients.

23. The I-SBC shall be able to enforce service level agreements (SLA) according to the limits
and features agreed upon with the peer network provider

24. The CSCF should support message manipulation support for all SIP messages which
includes:-

 Standard SIP headers and message body

 Non-standard SIP message and body types

26. The P-CSCF must be compatible with UEs that do not support SigComp. That is, the P-
CSCF must support uncompressed mode of operation for SIP signaling.

27. The P-CSCF should be able to prioritize emergency calls in high priority to ensure
emergency calls be served even in congestion situations.

28. In case of HSS outage the I-CSCF should support S-CSCF Determination

29. P-CSCF must suggest I-CSCF Finding scheme using domain name.

30. There should be Support of Bi interface in P-CSCF

31. P-CSCF should support Lawful Interception.

32. The IMS core should support 3GPP standard IMS Roaming deployment:

33. The P-CSCF should support Codec Filtering and Packetization Control

34. In case of a sudden packet bearer loss (e.g. subscriber drives into a tunnel) the P-CSCF is
informed by the PCRF via the Rx interface. The vendor shall describe the behavior of the P-
CSCF within such a scenario. In particular, the P-CSCF should de-register the subscriber in
the HSS within this scenario

35. In case of collocation of one or more functions sharing the same hardware with the offered
P-CSCF it must be ensured that each function gets the granted hardware resources

36. The P-CSCF must support the following P-Headers

 P-Access-Network-Info
 P-Asserted-Identity
 P-Associated-URI
 P-Called-Party,
 P-Charging-Function,
 P-Charging-Vector

37. The vendor shall support the following security algorithms on the P-CSCF.

IPSec ESP Encryption Algorithms:

 Null (no encryption applied)

 AES-CBC with 128 Bit key
 3DES-CBC

IPSec ESP Authentication Algorithms:

 HMAC-SHA1-96
 HMAC-MD5-96

39. The vendor shall explain if a Web-RTC-GW functionality is integrated and available on the
same platform and the same SW Release as SBC.

40. The vendor shall explain in detail the security certifications of the A-SBC.

41. The SBC shall support Access Control List filter and classifiers, including of black, white and
default lists based on IP address/port or ranges and application protocol.

42. The SBC shall support configurable bandwidth policing (signalling and media)

43. The SBC shall support S/MIME protection of SIP messages.

44. The vendor should explain how traffic separation and security on layer 2 and layer 3 is
supported on outbound and inbound ports.

45. The A-SBC shall have the capability to handle SIP registration flooding and Emergency calls
shall always be possible.

46. The A/I-SBC shall support both MSRP B2BUA (RFC 4975, RFC 6135) and MSRP pass-thru
(RFC 6135).

47. The SBC may support insert of RPI (remote-party ID) header according to the P-Asserted-
ID.

48. Enhanced Single Radio Voice Call Continuity

49. The offered SBC shall provide Access Transfer Control Function (ATCF) as specified in
3GPP TS 23.237, Release 11.

50. The offered ATCF and ATGW shall support the Iq/Ix interface according to 3GPP TS
23.334, TS 29.162 respectively.

51. The ATCF should control the ATGW via H.248 protocol

52. Iq interface procedures relative to session and media anchoring for SRVCC shall be
performed by the ATCF for speech session transfer (PS  CS) using SRVCC enhanced for
ATCF procedures, as described in 3GPP Release 11 TS 23.237.

54. ATCF and ATGW shall have means to process calls towards the BGCF finally destined
towards the IMS-MGCF and -MGW to the CS-domain.

55. ATCF system shall support failover to the redundant (local or geographic) system without
impacting current session.

56. ATCF shall support the Iq interface to the ATGW as defined in 3GPP TS 29.334 rel 10 or
later.

57. ATCF shall support RFC 5002 P-Profile-Key Header.

58. Capacity and Performance

59. State the minimal/maximal number of subscribers that single Virtual Machine/Virtual
Network Function can handle.

60. The Vendor shall submit the maximal value of system performance and capacity (including
test condition, performance/capacity standards) on the condition below.

 CPU / Memory load must keep below 80% for maximal number of subscribers.
 The maximal value of system performance is accepted only when there is no lost call during
one hour.
 Both IPV4 and IPV6 must be provided with same level of performance.

62. Maximum capacity of each IMS component (e.g. BHSA, Number of messages/ concurrent
sessions /transactions per second) that can be handled by the proposed system
configuration over a sustained period of time without degrading performance shall be
provided. Detailed information on how to accomplish such the maximum traffic performance
shall be included also.

63. Vendor shall clarify the sources for auto-scaling triggering events and the applied
criteria/thresholds.

64. Vendor shall explain whether the scaling solution can be implemented based on traffic
prediction, for example, historical traffic and idle/busy time range.

65. CSCF at each site must be addressed by a single IP address with other nodes. This unique
IP address must not in any event impacting performance and scalability of the solution.

66. The vendor shall state the support of the single software parameter concept based on
SIMULTANEOUSLY ACTIVE USERs according to the definition provided above.

67. IMS Core nodes shall be equipped and configured redundantly with the necessary features
in order to support geographical redundancy and 99.999% availability.

68. The vendor shall list all other impacting items, means any additional condition required as
input for proper performance and capacity calculations.

69. The vendor shall provide its IMS Traffic Profile for the A/I-SBC ,applicable for IMS (e.g.
VoLTE) deployments. The vendor’s currently valid traffic profile shall be provided.

70. The vendor shall provide a fully detailed description of the minimum meaningful
configuration of its VNF, explaining its maximum supported capacity figures for the following
parameters: Session attempts in BH, Successfully Established Sessions in BH (SESBH),
throughput (Concurrent Multimedia Sessions), registered users, SIP messages per seconds
and charging transactions per second.

71. The vendor shall state whether and how much an increase of online charging messages
impacts the maximum number of supported ‘Session attempts’ and any other relevant
capacity and performance parameter.

73. State the maximum capacity of the system, power consumption and Availability.

74. State the Maximum sessions that A-SBC can handle per second (Sig and Media).

75. Traffic Profile

76. CSCF Functional Requirements

77. General Requirements
78. Describe the architecture and various platforms supported by Suppliers’ CSCF solution.

79. Mention the various key features supported by suppliers’ CSCF solution.

80. Please provide the all interfaces and protocols supported by CSCF.

81. CSCF functionalities

82. Interrogating Call Session Control Function (I-CSCF)

83. The I-CSCF should support the following interfaces as defined within the relevant 3 GPP
standards

 Cx interface and associated functional behavior as described in 3GPP TS 29.228 and

3GPP TS 29.229 to the HSS.
 Mw interface to the P-CSCF and S-CSCF and associated functional behavior as described
in 3GPP TS 24.229

85. During initial registration if the I-CSCF cannot connect to the selected S-CSCF it should
select a new S-CSCF the procedure may be explained

86. If the user registration status response doesn't contain any Server-Capabilities AVP, the I-
CSCF shall select an S-CSCF based on local configuration.

87. I-CSCF shall be able to perform ENUM before Cx Query and shall perform ENUM for transit
routing.

88. I-CSCF shall be able to perform offline charging via the Rf interface according to the 3GPP
TS 32.240, TS 32.260 & TS 32.299.

89. I-CSCF shall provide a mechanism to configure the trusted domain list.

90. Serving Call Session Control Function (S-CSCF)

91. For interworking with HSS regarding subscriber information, Shared IFC must be provided
.

92. The S-CSCF must be able to route SIP messages to the appropriate AS(s) based on initial
Filter Criteria obtained from the HSS.

93. The S-CSCF should be able to distinguish between the ISC interface traffic and
Mw/Mi/Mg/Mr traffic in particular. Please indicate how this is distinguished

94. The IMS system shall support 3GPP Initial Registration, Implicit Registration, Explicit
registration, Re-Registration and De-Registration.

95. The proposed system must provide accommodation of multi domain subscribers.

96. The proposed system must provide multi login such as multiple public user identities or
multiple private user identities by subscriber.

97. Registration of multiple devices for the same public user identity must be supported to
provide “one phone number for multiple phones” service and forking feature must be
provided.

99. Provide List of different authentication schemes supported.

100. IMS core shall support assignment of an alternative S-CSCF for a registered user,
when his previously assigned S-CSCF is not available anymore.

101. According to 3GPP TS 23.228 TS 24.229, the S-CSCF should support de-
registration triggered by IMS HSS FE or S-CSCF internal events.

102. The proposed system must provide conversion between Tel-URI and SIP-URI
through ENUM interworking.

103. If HSS interworking is failed, when request for re-registration is made, transmission
of success response to the terminal without diameter query through HSS must be
suggested.

104. It should be possible to perform re-registration even in case of an HSS outage

105. It should be possible to, serve terminating non-REGISTER requests for registered
users.

106. There should be a mechanism on Cx interface to monitor number of application

specific error code received on primary connection and to switch over the complete traffic to
alternate connection for specified time interval

107. There should be a counter that provides peak performance measurements for the
fully registered subscribers per specific service as specified in the subscriber profile

108. The proposed system must provide call forking in case of multi binding is required
and a specific method must be suggested.

109. S-CSCF shall support for Mission Critical Push To Talk over LTE (MCPTT).

110. S-CSCF shall support Calling number verification support with STIR-SHAKEN.

112. S-CSCF shall support Central User Authorization via LDAP.

113. Transit Control Function (TRCF)

114. In case the IMS network is neither directly serving the calling nor the called
subscriber a SIP request is routed towards the TRCF, being responsible for interconnecting
neighboring networks. The transit support should comprise of routing, service triggering, and
charging.

115. TRCF must provide support for Rf interface.

116. TRCF must provide support for Lawful Interception Management.

117. Breakout Gateway Control Function (BGCF)

118. Please describe your vBGCF and provide all supported features.

119. Suppliers’ BGCF shall support Rf interface for charging.

120. BGCF should support configuration of wildcard values in routing tables.

121. BGCF should support handling 3xx response from next hop, instead proxy the 3xx
response upstream.

122. Key Features

123. Overload Protection

124. Please explain the Overload control mechanism in the CSCF

125. The CSCF shall be able to protect the HSS-FE against Overload. Please explain
how it is achieved.

126. Emergency Calls should receive priority treatment even in overload conditions

128. Operator should be able to configure threshold limit per AS.

129. Please explain the Load Balancing and Failover mechanisms in the CSCF

130. LoPS (Local Plug in Service)

131. Supplier shall mention various Integrated features supported by its CSCF solution.

132. FEE (Feature expansion environment)

133. CSCF shall support Feature expansion environment to enable flexible programming
of SIP services directly.

134. CSCF shall support Centralized Transcoding with Feature expansion environment.

135. ICS (IMS centralized services)

136. Supplier CSCF shall support ICS-I2 interface for delivering CS domain services.

137. Explain the registration process of ICS users in IMS.

138. How an ICS user is de-registered when the UE moves between two ICS enabled
MSC-Server.

139. How an ICS user is de-registered when the UE moves from the ICS enabled MSC-S
to a non-ICS enabled MSC-S.

140. 5G support in CFX-5000

141. CSCF shall support 5G access type and cell-id configuration.

142. Supplier CSCF shall support charging interfaces to support the 5G access types.

143. CSCF on Virtualized platform

145. Your solution should be compliant to the ETSI NFV architecture

146. Please describe consequences according to your SW in case the underlying HW

changes (recompilation, performance effects, ...).

147. Which KPIs may trigger scaling actions? How these triggers are monitored?

148. Please describe your high availability concept.

149. What is your point of view on legacy and virtualized architecture coexistence
especially at the beginning of NFV implementation?

150. Please state VNFs shipped in a form of VM in what supported formats (raw, qcow2,
etc.)?

151. Please describe how load balancing is achieved for the workloads among VMs for
the same VNF.

152. Due to some services criticality, a proposed solution must guarantee Session
Continuity (With no Service Interruption) in the case of any HW/SW Failure. If supported,
please describe how this is achieved with the VNF redundancy design.

153. Please describe in details the VNFs licensing model and specify the difference with
the licensing of legacy solutions. It would be appreciated if the vendor could give some
VNFs licensing examples.

154. Please describe the essential differences between your legacy and virtualized
solutions?

155. CSCF VNFs should run successfully in a multi-vendor environment (Different

infrastructure vendors (Blades, Hypervisor, VIM) and different telco vendor solutions).

156. CSCF shall support Multiple IP support architecture.

157. Capacity and Performance

159. What is the max number of VMs that Current VNFs support?

160. The Vendor shall submit the maximal value of system performance and capacity
(including test condition, performance/capacity standards) on the condition below.

 CPU / Memory load must keep below 80% for maximal number of subscribers.
 The maximal value of system performance is accepted only when there is no lost call during
one hour.

162. Maximum capacity of each IMS component (e.g. BHSA, Number of messages/
concurrent sessions /transactions per second) that can be handled by the proposed system
configuration over a sustained period of time without degrading performance shall be
provided. Detailed information on how to accomplish such the maximum traffic performance
shall be included also.

163. Vendor shall clarify the sources for auto-scaling triggering events and the applied
criteria/thresholds.

164. Traffic Profile

165. The vendor shall provide its IMS Traffic Profile for the I/S-CSCF and BGCF,
applicable for IMS (e.g. VoLTE) deployments.

166. HSS Functional Requirements

166.1.1 The solution architecture shall support separation of the HSS application Logic from the
subscriber database

167. Subscriber Authentication

168. HSS shall support SIP Digest Authentication via Cx interface as specified in
3GPPTS29.228 and 29.229

169. The IMS system should support authentication intended for use with early IMS end-
user devices that are not equipped with a UMTS subscriber identity module.

170. The solution must support IMS AKA over IPsec authentication for 2G/3G and LTE
users as specified in 3GPP TS 33.203

171. The HSS must support IMS AKA authentication over TLS version 1 and version 2

172. The solution must support the NASS-bundled authentication for fixed subscribers.

173. Access Authentication

175. HSS shall support EPS AKA access authentication

176. HSS shall support the generation of AKA based authentication vectors where SQNs
are different for different AKA methods. The segmentation should be achieved by
configuration of the access specific IND (index) ranges

177. HSS-FE shall use its own or an external AuC for authentication vector generation

178. The HSS must support Legacy access authentication and provide authentication
vectors via S6D interface

179. Identity Management

180. The subscriber authentication must support the IMS Identity Management for IMS
and NON-IMS services.

181. The HSS should support multiple Public User IDs, multiple Private User ID, multiple
Implicit Registration Sets and multiple Service Profiles per subscription.

182. The HSS shall support display names within the network according to 3GPP TS
29.228 and also support display names towards the end-user device.

183. HSS Features

184. The HSS shall support interworking with HLR

185. The HSS should support the S-CSCF restoration process, if the CSCF
behaves according to 3GPP TS 29.228

186. HSS should support direct support for PSI.

187. HSS shall support subscriber specific Tracking area update timer.

188. HSS shall store timestamp data of last location.

190. HSS shall support closed subscriber user group feature,

191. HSS shall support QoS parameters (UE-AMBR, QoS class id, ARP AVP etc.)

192. HSS shall support multicard subscription for EPC.

193. HSS shall support shared IMPU on Sh interface.

194. HSS shall support enhanced multimedia priority services for EPC and IMS
scenarios.

195. HSS shall support procedure for IPSM-GW registration via Sh interface.

196. HSS shall support IMSI changeover feature.

197. HSS shall support MultiSim feature.

198. HSS shall support store and forward UE-SRVCC capabilities towards SCC-AS

199. HSS shall support Query VoIP bearer support (T-ADS).

200. HSS shall support Store and forward dynamic STN-SR towards serving node.

201. HSS shall support distinct PSI for optimized routing.

202. To Support eSRVCC in visited network, either distinct or wildcard PSI shall be
provisioned in HSS

203. HSS shall support Inter-RAT PS Handover.

204. HSS shall support below features:

 Restoration priority.

 Terminating Access domain selection for VoLTE and VOWifi subscribers

 ICS Indicator specifies whether or not the subscriber is an ICS user as per 3GPP TS 23.292

 Network Provided Location Information NPLI

205. The solutions shall allow for IMS subscribers with voice and SS services controlled
by the Telephony AS the suppression of ODB in CS domain and in the HPLMN

206. The solutions shall allow for IMS subscribers with voice and SS services controlled
by the Telephony AS the suppression of ODB PLMN in CS domain and in the HPLMN and
VPLMN

207. The solutions shall allow for IMS subscribers with voice and SS services controlled
by the Telephony AS the suppression of ODB premium and / or information in CS domain
and in the HPLMN

208. Security
209. Authentication between IMS subscriber and IMS network shall follow IMS AKA
(Authentication and Key Management) as specified in TS 33.203.

210. HSS shall support host-based firewall mechanism.

211. HSS shall support supervision of DoS attacks.

212. Session and Service Control

213. To control sessions and services of an IMS subscriber, the HSS, interacting with the
CSCF, shall provide the following features:

 Session control
 Service control
 Service triggering with initial filter criteria

215. Load Balancing and Failover

216. HSS-FE should support N+K multi-site Geo-redundancy.

217. Describe how a client can connect to the geo-redundant site in case of a disaster.

218. HSS system shall support local redundancy

219. HSS shall support SW recovery. A continuous is-alive protocol shall be used to
monitor all essential software units and to recover them if necessary

220. If an HSS-FE has no access to its subscriber repository, it automatically should

reroute incoming requests to other HSS-FE’s

221. The Vendor HSS-FE should provide failover support by responding with the
capabilities for the IMS unregistered user in case of non-availability of the S-CSCF
assigned to that user

222. HSS-FE should support DIAMETER Overload Control to prevent traffic congestions.

223. Interfaces and Protocols

224. HSS solution should support LTE (as defined in TS23.401) including S6a- and SWx
interface.

225. HSS Front-End system shall support Cx interface as defined in 3GPP TS 29.228
release 10 or later.

226. HSS shall support all the Diameter parameter definitions as defined in 3GPP TS
29.230 release 10 or later.

228. HSS FE should support S6m interface as per the 3GPP specifications and provides
the subscription information of any MTC device.

229. HSS FE should support SLh Diameter based interface which is between the CMS-
8200 HSS and the Gateway Mobile Location Center as described in 3GPP TS 23.271 (stage
2) and 3GPP TS 29.173 (stage 3)

230. Capacities and Performance

231. IN the HSS architecture it shall be possible to scale application and database
independent of each other.

232. The HSS architecture shall be scalable in terms of adding nodes in new sites as well
as in already existing sites.

233. Operation, Administration and maintenance

234. HSS shall provide the alarms & OMs necessary for monitoring the status and health
of the platform.

235. The HSS shall provide detailed alarm information in the alarm notification sent to the
management system.

Notifications should include:

 location of the alarm

 time the alarm occurred
 perceived severity of the alarm
 alarm description
 alarm category
 alarm type

236. The NE will be capable of buffering more than 48 hours of accounting data, to
ensure continuity in case where the transport to upstream systems is not available.

238. The HSS FE provides should provide performance information on a per-peer-node

basis. i.e HSS should count events at various interfaces including S6a/S6d, Sh, SWx, Cx
and Wx.

239. The HSS-FE solution also supports a Central Log Collection mechanism

240. HSS Database Requirements

241. The supplier shall state the type of database standard chosen for subscriber
database.

242. The supplier shall provide the description about Directory service concept in HSS
database.

243. Data (subscriber) model shall be extendable in order to be used in future by other
applications.

244. The supplier shall state the interface protocol(s) available in subscriber database
provisioning system.

245. Provisioning system shall allow performing the Bulk update for user profiles. The
supplier shall state which type of data can be updated by batch processing.

246. The supplier must provide in details how the HSS database is configured and how
they retained the synchronization and data integrity among the proposed servers.

247. HSS on Cloud Infrastructure

248. The proposed HSS/AuC solution should be compliant to the ETSI NFV architecture
on Telco Cloud.

249. Please provide the architecture for the implementation of the HSS Telco Cloud.

250. The VNF must be managed by a VNFM by means of a generic set of industry-
standard operations and interfaces.

254. ENUM/DNS Features

255. ENUM shall support NAPTR, SRV, AAAA, PTR resource records.

256. ENUM shall support a configurable ENUM domain (e.g. “e164enum.net”).

257. Describe ENUM server interface for exchange of NAPTR records.

258. ENUM translation shall be provided as specified in 3GPP TS 23.228.

259. The ENUM client/resolver shall support several ENUM roots.

260. The ENUM solution shall be compliant with GSMA IR.67 "DNS Guidelines for
Operators".

261. ENUM/DNS shall support subsequent MNP query based on SIGTRAN

(SCTP/M3UA) towards STP layer.

262. Possibility to export Full configuration with a customize name and to send to a
central SFTP server by means of scheduled task.

263. ENUM shall be able to keep an internal MNP database.

264. Upon failure of signaling towards NPDB, the ENUM system shall be able to
generate ENUM response messages that contain error codes that enables the ENUM
request originating node to initiate relevant fault handling procedures, such as e.g. failover to
redundant node.

265. Upon failure of signaling towards NPDB, the ENUM system shall have an option to
suspend operation until NPDB communication is restored.

267. Inquiries towards MNP shall be possible as part of the DNS/ENUM procedure.

268. The solution shall support NTP (Network Timing Protocol, IETF RFC 1305).

269. Network nodes shall support Path MTU Discovery for IP version 6 as specified in
[RFC1981].

270. Network nodes shall support Neighbor Discovery for IPv6 as specified in
[RFC2461].

271. Network nodes shall support ICMPv6 as specified in [RFC2463].

272. The proposed system shall support SOAP protocol.

273. The DNS/ENUM server will be deployed in a hierarchical architecture, as e.g. a Tier-
1 or Tier-2 server, in a flexible manner.

274. The proposed system shall support automatic and manual backup; support restore
configuration. Please describe how to roll back to the previous configurations.

275. The proposed system to upgrade and downgrade software version.

276. The proposed system shall support Number Portability (NP) service and
interconnect with existing NP database. The Bidder shall describe the solution in detail.

277. The ENUM Server shall answer to the respective queries dependent on the
originator of the request. The DNS/ENUM Server must support the concept of the so-called
‘view’.

278. The ENUM Server shall support caching of DNS or NAPTR records in ENUM client,
by e.g. providing as part of the DNS or NAPTR answer appropriate and configurable TTL
values.

279. If prefixes are exchanged with a customer via a routing protocol, the maximum
number of prefixes must be limited.

282. The AP shall authenticate all XCAP requests to TAS.

283. The AP shall support authentication of users from multiple-domains.

284. The vendor shall describe the method for selection of any TAS instance to send
request on Ut interface (it will not be mandatory to send it to same TAS which is holding
subscriber Registration information).

285. Authentication Proxy shall support capability to behave as a reverse and trusted
proxy acting as the single point of contact for all clients XCAP self-admin requests.

286. The AP shall support both absolute and relative HTTP request URI's coming from
XCAP clients.

287. The AP shall support Ub server functions.

288. The AP shall support IPv4, IPv6 and dual stack clients.

289. The AP shall support deployment in High-Availability configuration.

290. The AP shall support deployment in Geographically Redundant configuration.

291. The AP shall support capability to act as a load balancer for XDMS servers.

292. The AP shall support handling of failure responses from the XDMS servers.

293. The AP shall support routing XCAP requests to/from domains of different operators.

294. The AP shall support outbound and inbound roamers XCAP requests.

295. The AP shall allow each ICS (IMS Centralized Services) subscriber to independently
access and update their supplementary service settings.

297. The proposed authentication mechanism for Ut interface shall comply with General
Authentication Architecture procedure as specified in 3GPP TS 33.222.

298. Capacity and Performance

299. Please describe what are configurations are supported by suppliers ENUM solution
and what is the capacity of each configuration?

300. Please describe how much resource does each configuration require and what
performance metrics are guaranteed for each configuration?

301. What is the max number of VMs that Current VNFs support?

302. Traffic Profile

303. The vendor shall provide its IMS Traffic Profile for the ENUM/DNS and Ut-Proxy
roles, applicable for IMS (e.g. VoLTE) deployments.

304. Application Server Functional Requirements

305. General Requirement
306. The Application server should provide voice, video, messaging services for 2G, 3G,
4G, CDMA, WiFi and 5G users of mobile, fixed and enterprise segment.

307. The Application server should provide IP-Centrex and PBX trucking features for
operator hosted mobile and fixed access.

308. The Application server should be access agnostic and 5G ready.

309. The Solution shall support Telephony Application Server, MMTEL AS, IM-SSF,
MRF, SCC AS and IP-SM-GW functionalities in a single entity.

311. The Application server shall be able interact with other SIP based services via
standard 3GPP SIP profile as defined in 3GPP 24.229.

312. The Application server should work as B2BUA mode for the service handling.

313. The Application server shall enable integration with proven Back-end interfaces for
O&M, Charging and Lawful Interception.

314. The Application Server shall support 3GPP online/offline charging architecture and
interfaces defined for IMS in 3GPP TS 32.240, TS 32.260.

315. The proposed solution shall support provide an open Application Programming
Interface (API) for quick development of new services, such as multimedia services.

316. Telephony Application Server

317. Architecture and Functions

318. What are the functionalities provided by the TAS List supported hardware
platforms?

319. The virtualized solution shall be compatible with both VMWare and KVM/OpenStack
environments. The supplier shall provide details of the versions supported in both
environments

320. Offered Application server should support operational excellence with robust internal
and external OAM framework.

321. Offered Application server should support Backup and Restore Function.

322. List down the functions offered by TAS over ISC interface.

323. SIP RFCs. Application Server should support seamless upgrade with no interrupting
active services by upgrading two planes separately, that’s is, one for providing services, the
other one for SW upgrade. The bidder shall elaborate how the concept can be implemented.

325. IMS AS should be able to offer modular functions or roles, where operator should be
able to suppress one or more functions of TAS.

326. TAS should be based on ETSI NFV compliant architecture. The TAS VNF should be
composed of VNFC (VNF Components).
Further the TAS VNFCs should be implemented by virtual machines (VMs). The TAS
VNFCs mapping to virtual machines (VMs) should be described.

327. The TAS application should be based on Micro-service architecture, enabling

DevOps based delivery model.

328. TAS should serve to a wide range of subscriber including consumer VoLTE ,
Enterprise and fixed.

329. The TAS VNF modelling and Lifecycle Management event definition should be
via open and community driven templates and template frameworks:

a) The TAS should support TOSCA/YAML based VNFD as per ETSI NFV (phase 2)
b) VNF modelling with OpenStack Heat Template (HOT)
c) LCM (Life Cycle Management) event definition through Mistral workflows
d) VNF commissioning via Ansible playbook.

330. Strategy & Compliancy with GSMA and 3GPP standards:

331. The bidder may also describe his involvement in any other relevant standards
bodies.

332. The AS (SCC AS, MMTEL AS, IMSSF) shall interwork with IMS solution compliant
with GSMA PRD IR.92 document for Volte.

333. The AS (SCC AS, MMTEL AS and IM-SSF) shall support SIP header transparency.

334. The AS should implement Release 10 mid-call support for SRVCC calls, as
specified by 3GPP TS 23.237 and TS 24.237.

336. Diameter protocol operations should be compliant with RFC4006, RFC6733

(obsoleting RFC3855), and 3GPP TS 32.260

337. Media availability

338. The AS shall support all media in SDP offer/response and particularly the media
profile defined in the GSMA IR.92, and GSMA IR.94.The SCC AS, MMTel AS or IM-SSF
shall accept HD Audio and Video communications.

339. The Solution must be able to generate both tones and voice announcements to
calling and called parties.

340. The Application Server shall control the media services over the Mp or Mr'
interfaces.

341. The Application server supports the following MRF media processing functions:

 Audio codecs, for example, G.711 A-law, G.711 u-law, G.722, G.729AB, AMRNB ,AMR-
WB, EVS
 Dual-tone multifrequency (DTMF) handling
 Fixed and variable announcements
 Multilingual announcements (40 languages/dialects and growing)
 Tones/announcements stored inside the media server or on external NFS, RTSP, and
HTTP servers
 Rich audio and mixing and conferencing capabilities, suitable for ad-hoc conferencing.

343. TAS should support co-location of various functions and services. Ideally, co-
location that provides advantages like signaling optimization (reduce the load on external
nodes), better services interactions, more compact platform, etc

344. TAS implementation shall support redundancy on network element level (e.g. high
availability cluster, pooling, hot-standby concept).

345. Overload handling in TAS

346. Please explain the Overload control mechanism in the AS

347. Please explain the Load Balancing and Failover mechanisms in the AS

348. MMTEL AS

349. STANDARD SUPPLEMENTARY SERVICES for Mobile Volte Subs.

350. General Requirement

351. The AS should support all necessary supplementary services as defined as in

GSMA and 3GPP specifications.

352. Originating Identification Presentation (OIP) - Originating Identification

Restriction (OIR)

353. MMTel AS should be compliant with 3GPP TS 24.607

354. MMTel AS should support “OIR per call” based on a predefined prefix added to the
called party number by the originating UE.

355. Communication Diversion (CDIV)

356. The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.604
and GSMA IR92 recommended options.

 Communication Forwarding Unconditional

 Communication Forwarding on not Logged in
 Communication Forwarding on Busy
 Communication Forwarding on not Reachable
 Communication Forwarding on No Reply
 Communication deflection

357. The MMTel AS should support upto 5 diversion destinations. It should direct the call
to VMS upon reaching the maximum value.

358. Communication Hold (HOLD)

359. The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.610.

360. The MMTel AS should support sending, as an option, a "Hold" music or video to the
held party when the call is placed on Hold.

361. Communication Waiting (CW)

362. The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.615.
Additionally, Both Network based, and user-based call waiting should be supported including
support for NDUB call case.

363. Call Waiting activation and deactivation should be manageable over an Ut interface
using XCAP protocol as described in 3GPP TS 24.623 and the XML schema defined in TS
24.615.

364. Communication Barring (CB)

The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.611 and GSMA IR92
recommended options.

 Barring of All Incoming Calls

 Barring of All Outgoing Calls
 Barring of Outgoing International Calls
 Barring of Outgoing International Calls – ex Home Country
 Barring of Incoming Calls - When Roaming

366. Playing of announcement, to the barred user when his call is rejected, by using
early-media procedure, for all the types of call barring should be supported. It shall be
possible to play a specific announcement associated to the call barring reason

367. The following Operator Determined Barring categories should apply for the call
transfer case:

 Barring of invocation of any call transfer (BI)

 Barring of invocation of call transfer where the served subscriber is charge (BIC)
 Barring of invocation of call transfer where the served subscriber is charged with
international rates (BICI)
 Barring of invocation of call transfer where the served subscriber is charged with inter-zonal
rates (BICZ)
 Barring of invocation of call transfer where both calls are charged to the served subscriber
(BICB)

369. MMTel AS shall support Ut interface using XCAP as described in 3GPP TS 24.623.

370. The offered MMTel function shall be compliant with 3GPP TS 24.623,

371. MMTel AS shall be able to receive notification about data modification (especially
the user service configurations).

372. Authentication Proxy in the Ut interface path should be supported.

373. Application server should support supplementary services manipulation through

facility codes over Ut interface.

374. LOCATION and Fax services

375. For originating calls, the MMTEL AS shall use the location information provided by
the PANI header. It shall use it as necessary (Communication Barring while roaming,
charging...). When the MMTEL AS and SCC AS are collocated, they may share the location
information directly.

376. MMTEL AS should support PANI header to for location retrieval.

377. For terminating calls, the MMTEL AS shall retrieve subscriber location and use it as
necessary (for Communication Barring while roaming, charging ...).

378. TAS should support LTE location mapping to 2G/3G location, so that it can be
utilized by backend applications, such as, for example, the SCP or the Billing Center, without
any logic or infrastructure change.

379. STANDARD SUPPLEMENTARY SERVICES for Fixed Subs.

380. The AS should support all necessary supplementary services as defined as in

GSMA and 3GPP specifications for Fixed Subscribers.

381. Supplementary services for Fixed Subs.

382. Advanced Conference (with Push to Conference)

384. Automatic Call Back

385. Automatic Recall

386. Call Barring (Outgoing Calls)

387. Call Blocking (Incoming Calls)

388. Call Completion to Busy Subscriber (CCBS)

389. Call Duration Limits

390. Call Forwarding (CFA, CFNR, CFB, CF Default, Unregister)

391. Call Transfer

392. Call Waiting

393. Calling Line ID (CLID, etc.) and Calling Name

394. Call Forwarding Not Reachable, Call Deflection

395. Call Forwarding (Local, Inhibiting Incoming Bear Based

396. Calling Party Category

397. Carrier Selection and Pre-Selection

398. Do Not Disturb

399. Emergency Service

400. General Reset

401. Hotline

403. Operator Determined Barring

404. Outgoing Call Barring (administrative)

405. Selective Call Acceptance (SCA)

406. Selective Call Forwarding (SCF)

407. Selective Call Rejection (SCR)

408. Selective Distinctive Alerting

409. Sequential Ringing

410. Service Suspension

411. Simultaneous Ringing

412. Speed Dialing (1 or 2 digit)

413. Subscriber Control of Language Setting

414. Support of Personal Ring-back Tones

415. Trusted Far Party Transfer

416. User Controlled Call Barring and Call Lock

417. Voice Messaging Interfaces

418. Warmline

419. STANDARD SUPPLEMENTARY SERVICES for Business Subs.

420. The AS should support all necessary supplementary services as defined as in

GSMA and 3GPP specifications for Business Subscribers.

422. Alternate Routing for PBX

423. Advanced Conference (with Push to Conference)

424. Anonymous Call Rejection

425. Automatic Call Back

426. Automatic Recall

427. Call Barring (Outgoing Calls)

428. Call Blocking (Incoming Calls)

429. .Call Completion to Busy Subscriber (CCBS)

430. Call Duration Limits

431. Call Forwarding (CFA, CFNR, CFB, CF Default, Unregister)

432. Call Forwarding (Local, Inhibiting Incoming Forwarded Call, Bearer Based CF)

433. Call Transfer

434. Call Waiting

435. Calling Line ID (CLID, etc.) and Calling Name

436. Calling Party Category

437. Dial Feature Code Interrogation

438. Do Not Disturb

439. Emergency Service

441. General Reset

442. Hotline

443. Intercept Referral .

444. IR.92 Call Barring and Blocking

445. Large Call Limit

446. Line Status Check

447. Location Based Call Services

448. Managed Call Recording

449. Message Waiting Indicator w/ Subscribe/Notify

450. Multiple Devices with Shared PUID

451. Multiple Ring Patterns (Distinctive Ringing, Multiple Directory Number)

452. Music On Hold

453. N-way Conference Calling

454. Operator Determined Barring

455. Outgoing Call Barring

456. PBX Interface – Registered Services

457. PBX Interface – Unregistered Service

458. Phone Context

460. Selective Call Acceptance (SCA)

461. Selective Call Forwarding (SCF)

462. Selective Call Rejection (SCR)

463. Selective Distinctive Alerting

464. Sequential Ringing.

465. Service Suspension

466. Speed Dialing (1 or 2 digit)

467. Sh interface for subscriber data

468. Simultaneous Ringing

469. Subscriber Control of Language Setting

470. Support of Personal Ring-back Tones.

471. Transit Routing

472. Trusted Far Party Transfer

473. User Controlled Call Barring and Call Lock

474. VPN Dialing and Display

475. Warmline

476. Account Codes

477. Advice of Charge (basic)

479. Answer Confirmation (SimRing, SeqRing, Extensions, and Adv Conf)

480. Authorization Codes

481. ISDN PRA trunking

482. Call Park and Call Pickup

483. Closed User Group for Centrex

484. Direct Dial to Voice Mail

485. Direct Inward Dialing

486. DN extension

487. Dual Mode Handset (DMH) Extension

488. Dual Persona

489. Public Service Identity Server

490. Call Limit Group

491. ISDN Large Call Limit

492. Listen in to Voicemail and Rescue

493. Multiline Hunt Group

494. Multiline Hunt Group with Queuing

495. Partial Routing/Call Deflection

496. Priority Mode Calling

498. Reminder Call

499. Simultaneous Ringing Call Transfer

500. Sub Addressing

501. Transfer to User’s Voicemail

502. User to User Signaling 1 Implicit

503. VPN International Least Cost Routing

504. VPN Least Cost Routing

505. INTERFACES

506. The MMTEL AS server has interfaces with the following functional entities:

The User Equipment (Ut reference point);

 The S-CSCF (ISC reference point)

 The I-CSCF (Ma reference point);
 The HSS, to transfer User Profile information or to access User Location (Sh reference
point)
 The MRFC to exchange session control messages without passing through an S-CSCF
(Mr’ reference point);
 The MRFC, to fetch and cache documents and resources from an MMTEL Server and to
return data to this MMTEL server (Cr reference point).
 The charging servers

508. ADVANCED SERVICES OR SPECIFICITIES

509. Sequential ringing

510. MMtel AS should support a Sequential ringing service

511. Simultaneous ringing

512. The MMtel AS should support a Simultaneous ringing service

513. MMTel services data storage and configuration

514. The offered MMTel function shall support the Sh interface compliant with 3GPP TS
29.328,

515. MMTel AS shall be “data less” and shall store data in a common database
repository.

516. When using the HSS as an external DB, using Sh interface

517. Multi-device and Flexible Alerting

518. The TAS should support Multidevice feature. User having multiple devices shall be
able to register with one common public identity, regardless of used access (CS/IMS) and
service (Voice/Video/SMS/RCS).

519. There is a challenge with subscribers who have a VoLTE device with CS-capability
and when the network supports both IMS and CS- registrations. Special attention is needed
for terminating domain selection which cannot be solved with IMS forking. The TAS should
solve this challenge by addressing a single device per INVITE request utilizing
sip.instance.ID.

520. When user wants to move a call from one device to another device it should dial an
Inter UE transfer number . Based on this transfer number Open TAS should execute the
session transfer. .

522. Architecture and applications

523. The MMTel AS and IP-SM-GW should support IM-SSF functionality.

524. The proposed IM-SSF shall support CAMEL phase 1, 2, 3 and 4 protocol for legacy
service integration with our existing SCP and compliant with 3GPP TS 23.078, TS 29.078
and AIS CAMEL specification provided in Appendix 2-8 of this RFP.

525. The proposed IM-SSF shall support the 3rd party registration procedure for
downloading the CAMEL subscription form IMS-HSS.

526. The proposed IM-SSF shall support IN service triggering base on CAMEL
subscription information.

527. IM-SSF to HLR/HSS

528. The IMSSF shall retrieve the IMSI when the subscriber is on IMS or when he is on
CS. The following methods shall be supported:

 Third party registration on IMS

 HLR/HSS interrogation (when the IMSI is not known)

530. IM-SSF to MRF

531. The IM-SSF shall be able to control an MRF to play the tone seamlessly to the
subscriber.

532. SCC AS
533. The vendor shall describe the offered SCC-AS functions.

534. The offered SCC-AS shall be compliant with 3GPP TS 23.237 Release 10.

535. The offered SCC AS shall support Camel based homing as an alternative to be
compliant with the guidelines provided in GSMA IR.64 IMS Service Centralization and
Continuity Guidelines.

536. The SCC AS shall be able to update the HSS profile or to fetch the C-MSISDN from
the HSS.

537. The SCC AS shall support the Sh interface to query the HSS for IMS Voice over PS
supported indication and RAT type

538. The offered SCC AS shall support Terminating Access Domain Selection (T-ADS)
as specified in 3GPP TS23.292.

539. The SCC AS should support T-ADS capability for the access domain selection.
Vendor shall describe the supported domain selection capabilities.

540. The offered SCC AS shall provide cohesive charging records with a complete
service continuity history for the whole duration of a subscriber multimedia session

541. The SCC AS shall be able to generate CDRs. The CDR format shall be compliant
with 3GPP TS 32.297, Release 10.

542. The SCC AS shall support Sh-interface for the STN-SR update and T-ADS, please
explain the functionality.

544. IP-SM-GW
545. The vendor shall describe the offered IP-SM-GW function.

546. The offered IP-SM-GW function shall be compliant with 3GPP 23.204, Release 10.

547. The offered IP-SM_GW function shall support the E/Gd interface towards the
SMSGMSC/SMS-IWMSC

548. The offered IP-SM-GW function shall support the J interface towards the HLR.

549. Functionality is required to be able to select the domain for message delivery
between IMS and CS/PS, and to have the message delivered to the selected domain

550. The IP-SM-GW shall provide the protocol interworking for delivery of the short
message between the IP-based UE and the SMS-SC.

551. The IP-SM-GW shall support service-level interworking between Short Messages
and Instant Messages in IMS as described in clause.6 3 of 3GPP TS 23.204.

552. The IP-SM-GW shall provide the protocol interworking for delivery of the short
message between the IP-based UE and the SMS-SC. The message is routed to the SMS-
SC for delivery to the SMS-based user or the message is received from the SMS-SC of an
SMS-based UE for delivery to an IP-based UE.

553. IMS USSD

554. The MMTel AS shall support IMS based USSD services.

555. AS should support USSD phase2 on MAP in MMI mode.

556. Please describe the impact on ongoing USSD session during SRVCC

557. IMS AS USSD functionality should be compliant to 3GPP standard 3GPP 24.390

558. Describe the charging mechanism for USSD services.

560. The Application server should provide State-of-the-art Service Creation Environment
service creation by the operator.

561. The Application Server should expose an open API, typically a call management
interface (Parlay X, CSTA, other…), for external applications or partners.

562. Application environment shall enable development using component model that is
based on standard framework.

563. Framework shall enable application components reusability in building various

services.

564. Services shall be implemented and programmable in standard languages with large
variety of developers available on the market (e.g. JAVA)

565. THE TAS SHOULD provide A framework for Java based Service Execution
Environment which enables fast creation of new operator specific services for instance to
replace current IN-solutions.

566. the TAS should provide a Service Execution Environment with Service Creation
Environment (SCE), Service Exposure API and SOA components for operator specific
interfaces and services.

567. PBX connectivity

568. The IP-PBX connectivity to Application server should be available by Hosted model,
where IP-PBX users/lines are registered to IMS and TAS, and TAS is providing the
supplementary services.

569. Application Application server should provide IP-PBX connectivity for

peering/Trunking solution where application server is providing network services to
unregistered subscribers.

570. Number portability

572. Telephony Application server and Registers

573. It should be possible to use existing HLR voice supplementary service subscriptions
also for VoLTE and for VoWiFi over MAP.

574. Proposed Solution it should be able to select the MMTEL repository based on
subscriber

575. The selection of the service repository should not impact the MMTel service
execution

576. Propose AS should support both Sh and MAP protocols for integration with MMTEL
repository.

577. Application server on Telco cloud

578. Which SW modules are implemented for your application server VNF and how they
map onto different VMs .

579. Supplier’s solution should be compliant to the ETSI NFV architecture.

580. The solution should support a high availability of 99.999%.

581. The solution shall support intra-site Live migration of a VNF instance (e.g. migration
between 2 blades of a cluster for maintenance purposes) The Bidder will indicate how this
migration could impact live traffic and the procedures to set-up to ensure Minimum service
disruption.

582. Which SW modules are implemented for your application server VNF and how they
map onto different VMs .

583. It shall be possible for the virtualized platform to be managed with the Traditional
Bare-Metal Platform

585. Capacity and Performance

586. State the maximum capacity of the system, power consumption and Availability.

587. Specify the recommended configuration per node in terms of CPU performance,
interface boards, number of processors, RAM size, disk type, disk space and any other
relevant data for dimensioning.

588. Application Server (TAS) should have ability to store all subscriber calls/event CDR
at least for 3 days.

589. How Does AS helps in preserving ongoing sessions from any service breakdown.

590. TAS should use its internal session database for intra-VNF resiliency and call
recovery purposes. Please explain how you support this functionality.

591. The Tenderer should describe, for each TAS platform during it normal operation, the
service related processing load distribution and balancing between the executive and the
redundant component.

592. Propose TAS platform shall support SCC AS and MMTel AS co-location. Describe
the platform performances and costs optimizations.

593. Active measurement, tracing and logs shall not adversely affect the behavior and
performances of the TAS node. Their impacts on performances shall be negligible.

594. In the dimensioning exercise the vendor shall take into account any side condition
specified in the reference Traffic Profile. It must be considered that the TAS node shall be
equipped and configured redundantly with the necessary features in order to support
geographical redundancy and 99.999% availability.

595. The Tenderer should describe the whole impact in the TAS platform functionality
and the associated service performance degradation when a failure occurs, until the switch-
over to the redundant module finishes. More specifically the following questions shall be
addressed in detail:

597. Is there any impact for the ongoing IMS services (e.g. already established sessions,
loss of registered contacts…)?

598. If the Vendor’s TAS system has the function that others don’t provide, or if it has an
advantage over any other’s products, please shall provide detail information for it.

599. The vendor shall explain in written form how the offered solution provides load
balancing across multiple processing elements or VNF instances and the type of load
balancing applied (stateful or stateless). If load balancers are involved in the supported load
balancing solution the vendor shall clarify how a failure in a load balancer entity is handled
to avoid the latter to become a single point of failure.

600. The dimensioning of the TARGET SOLUTION per shall be based on an engineering
limit of 70% capacity utilization for both physical (i.e. hardware) and virtual (e.g. VM)
resources.

601. Traffic Profile

602. The vendor shall provide its IMS Traffic Profile for the Application server, applicable
for IMS (e.g. VoLTE) deployments.

603. MRF Functional Requirements

604. MRF architecture and standards
605. Describe MRF architecture and components.

606. Media
607. The MRF shall support the media profile (Voice and Video) as required below:

 Codecs
o AMR speech codec modes 12.2, 7.4, 5.9 and 4.75

o ITU-T recommendation H.264 Constrained Baseline Profile (CBP) Level 1.2, 2.2 and 3.

 RTP

 RTCP Usage

 AMR Payload

 DTMF mechanisms

608. For potential fixed usages, the MRF should also support standard audio codecs.
Your MRF shall support the following codecs: G711 A-law and µ-law, G729.

609. MRF usage by the MMTel AS

610. The MRF should be used for all the MMTEL AS services that require media support.
The MMTel AS shall rely on MRF for all the services requiring audio media.

 Announcements
 Tones
 Conference (CONF service)
 Recording

613. State the vendor’s experience in handling large scale LTE/IMS deployments.

614. For interfaces carrying User Plane traffic, it shall be possible to set a maximum
bandwidth limit for outgoing Realtime traffic:

615. MRF on Virtualized platform

616. Your solution should be compliant to the ETSI NFV architecture

617. The NEs shall supervise its own functions and inform if a corrective action is
required in order to minimize the effect of the fault and performance

618. Scalability: The Design Must Support Any Future Expansions or Technology
Improvements, Upgrades, with The Minimal Hardware Changes.

619. Please indicate the various cloud stacks supported by the IMS VNF’s

620. The virtual appliance image MUST be in a format supported by OpenStack,

preferred format is a qcow2 image

621. MRF Shall allow implementation of dedicated Resource Network to obtain

announcements from centralized repository

622. MRF Shall offer means to transfer "bare metal" MRF configuration onto an existing
Virtual Machine with a proper guest OS

623. MRF shall offer means to deploy the MRF software using a vendor specific software
package

624. MRF shall offer System Logging and allow root cause analysis

626. A dedicated physical / logical interface must be used for management purposes.
The management traffic interface must be ‘out of band’ and separate from the interfaces
used for carrying control plane and/or user plane traffic.

627. To grant the reliability of log data must be paid to the completeness of the
information collected. From this, the requirement is to the log data transmitting network
protocol, to ensure completeness.

628. The system must provide the ability to automatically disable user accounts after a
set period of non-use.

629. Each identifier (account) needs to be assigned (principle of clarity and

comprehensibility) exactly one responsible user.

630. Anybody modification, blocking and deletion of accounts and permissions must be
clearly documented.

631. The ability to perform administrative procedures on databases using the underlying
operating system privileges is restricted to databases administrators only.

632. Capacity and Performance

633. State the maximal number of subscribers that single Virtual Machine/Virtual Network
Function can handle.

634. Traffic Profile

635. The vendor shall provide its IMS Traffic Profile for the MRF, applicable for IMS (e.g.
VoLTE) deployments.

639. The VIM shall maintain a repository of VNF images and provide a mechanism for
managing them (add / delete / update / query / copy) as requested by the NFVO or VNFM.

640. The VIM shall maintain an up to date inventory of the NFVI Hardware and Software
resources and the allocation of virtual resources to physical resources. The Supplier shall
describe how resource inventory information is synchronized with the NFVO and VNFM.

641. The VIM shall provide a mechanism for monitoring VMs that have bypassed the
hypervisor (e.g. by using SR-IOV, PCIe pass-through).

642. The VIM shall perform active checks for the well-being of the NFVI Hardware
Resources (compute, storage, networking), Software resources (hypervisors) and VMs to
guard against silent failures.

643. The VIM shall allow the migration of virtualized resources between locations, for
example, the migration of a VM from one physical machine (host) to another physical
machine.

644. The VIM shall be based on Openstack release Pike or higher and shall be kept
aligned to the latest current Openstack release.

645. The Supplier shall provide a description of any other API available on the VIM.

646. The supplier shall state whether they are implementing technologies such as SR-
IOV/DPDK and the specific reasons for this. If suppliers are using one technology over
another, they must clearly document why this is the case and any caveats or limitations of
this approach.

647. The Supplier shall describe any other data-plane acceleration techniques supported
by the Solution.

650. The VNF Manager shall be capable of instantiating VNFs, i.e. create a VNF using
the VNF on-boarding artefacts, including VNF configuration if required by the VNF
deployment template.

651. The VNF Manager shall be capable of scaling in-out VNF instances.

652. The VNF Manager shall be capable upgrading and updating VNF instances, i.e.
VNF Software upgrades and configuration changes of various complexity.

653. The VNF Manager shall be capable of terminating VNF instances, i.e. release VNF-
associated NFVI resources and return it to NFVI resource pool.

654. The VNF Manager shall be capable of healing a VNF instance in an assisted or
automated way.

655. The Supplier shall state whether their VNF Manager is a combined vendor "specific"
and generic VNF Manager in one, or if these functionalities are split out separately in their
architecture. The Supplier must explain their reasoning for taking one approach over the
other.

656. Hardware
657. The vendor shall describe the hardware platforms supported and their specifications

658. The hardware must meet the highest industry standard of high availability, fault
tolerance and scalability.

659. The System shall be designed without any single point of failure in term of
hardware, software, modules and interfaces.

660. The Supplier shall state the compliancy to all the relevant ETSI standards.

661. The Supplier shall state the compliancy to IETF standards.

663. The Supplier’s equipment shall comply with EN 300 386-2, environment class "other
than telecommunication centers".

664. Database hardware should be complies with RoHS standards in manufacturing and
deployment of equipment.

665. The system should comply with NEBS standard. Specify any other standard
supported by the system.

666. Please fill the Limits for temperature and humidity under which the system can
operate

667. The solution should support a reliability of 99.999%

668. Bidder's Data Center solution should be based on Open Compute Project Open
Rack V2 compatible Server V3 design.

669. Bidder's Rack shall support an input of 3 phase AC or -48 V DC and output should
be through 12.5 VDC busbar.

670. Each server should be dual socket with Intel processors of minimum 16 physical
cores each.

671. Each server should be populated with at least 192 GB DDR 4 memory

672. Each server should support up to 4 ports of 10GBE or higher ports shall be available

673. System shall provide standard monitoring capabilities and remote upgrade
capabilities via onboard BMC (Baseboard Management Controller).

674. Bidders Hardware should support acceleration methods such as application or I/O
acceleration techniques to reduce application load and enhance faster processing.

675. The proposed storage solution should be Software-defined for storage (SDS) and
should include advanced agility functions.

676. Each storage node should contain multiple disks to have higher storage density.

678. The bidder should include hardware management utility that shall enable:

 To maintain and upgrade multiple system firmware simultaneously

 To easily locate and manage servers and devices in the hierarchy

 To monitor power and thermal information in real time and check several system
thresholds

 To collect inventory data for further analysis and statistics with one click

682. The E-CSCF in accordance with the P-CSCF must support emergency call handling
for both registered and unregistered subscribers. Describe the emergency call procedure in
detail.

683. The E-CSCF should be able to differentiate between session-related and session-
unrelated SIP services

684. The E-CSCF should use the S-CSCF record format as defined in 3GPP TS 32.260.

685. The CSCF should comply to NENA i3 standard.

686. The E-CSCF must support the Ml interface toward location retrieval function (LRF).

687. The E-CSCF must route the call to the Public safety answering point (PSAP)
according to information received from routing decision function (RDF).

688. Emergency callback for accepting emergency calls even if a subscriber is not
registered, or for callbacks if a subscriber is registered should be supported

689. The E-CSCF must support Providing location information in an emergency call as
required by regulatory authorities in most countries

690. The E-CSCF must support emergency call routing translate the dialed emergency
number and the location information to the E.164 number of the emergency center that is
responsible for the emergency call.

691. Supplier’s CSCF should support E911 Emergency Call support for North American
market. Provide details for the same.

692. The E-CSCF must support Emergency call supervision for E911 call, dialog event
packages as specified in RFC 4235

694. Supplier’s E-CSCF solution shall support SRVCC for Emergency Sessions

695. Supplier’s EATF solution shall support high availability architecture.

696. Supplier’s EATF solution shall support offline charging with Rf (Diameter) interface.

700. Vendor shall mention all relevant 3GGP standards with which its Lawful interception
solution is complaint.

701. The Target subject should be intercepted based on several identities (MSISDN,
IMSI, IMEI and Sip-url, tel-url etc. Please provide details for the same.

702. If the supplier proposes its own Mediation Function platform, LI database shall be
encrypted.

703. X1 configurations/information shall not be visible by operators/administrators not

involved in Lawful Interception management

704. X1 interface on IMS equipment shall be secured (confidentiality & integrity).

705. When reporting LI event, target identities shall be encrypted in logs of the IMS
solution equipment

706. Lawful interception functionality in Application Server

707. The TAS+MRFP shall be able to identify the Interception Target with any of the
identities used by the TAS+MRFP to identify subscribers. Examples of such identities are
TEL-URI and SIP-URI

708. The TAS+MRFP shall support the lawful interception functionality for Call
Forwarding, Call Waiting, Explicit Call Transfer supplementary services (signaling and
media), Conference supplementary services (signaling and media), and Subscriber
Controlled Information (SCI) supplementary service.

709. All LI-related data that is processed in the TAS+MRFP shall be protected against
unauthorized access

711. What is the maximum number of Interception Targets that may be stored in the
TAS+MRFP. What is the maximum number of concurrent interceptions that may be taking
place.

712. Interception nodes shall have a configurable option to provide secure local buffering
of LI information (IRI) in the case of communications failure with the receiving node. The
vendor shall describe what kind of storage is used, whether it is internal or external to the
TAS+MRFP and how the information is secured.

713. The TAS+MRFP, either in itself or with support from the ADMF and DF, shall be
able to support target administration by, and interception product delivery to, multiple
LEMFs.

714. The TAS+MRFP shall support LI Provisioning via X1_1 interface and delivery of IRI
via the X2 (TAS) and CC via the X3 (MRFP) interfaces.

715. LI related information shall not be processed or transferred in any way during
normal network element troubleshooting (i.e. non LI troubleshooting). In particular, the
vendor must prevent any LI information being transferred in logs or software dumps.

 NMS System overview;

 NMS Hardware Configuration;
 NMS database and data model description;
 NMS open interfaces description;
 License management (NMS and network licenses administration);
 Backup/Restore/Recovery concept and configurations;

717.1.2 The Vendor shall comment on existing and planned compliance/non-compliance with
network management and element management information model standards and where
in the systems architecture the following standards will apply:

- 3GPP standards
- TM Forum MTNM
- OSS/J
- Other

717.1.3 The vendor shall deliver a Network Management System (NMS) that supports all relevant
functionalities, including, but not limited to Fault Management (FM), Performance
Management (PM), Configuration Management (CM) Security Management and
Accounting (Administration) Management for all network elements.

717.1.4 The NMS shall have a layered structure focusing on scalability, flexibility and openness.

717.1.5 The Tenderer shall furnish detailed systems architecture for the proposed EMS solution
based on FCAPS.

717.1.7 The NMS shall adhere to HA (High Availability) requirements. A yearly system availability
of minimum 99.99% shall be supported.

717.1.8 The NMS shall not be unavailable more than 2 subsequent hours in cases of downtime.
Allows the users to interact with the system and the NEs controlled by it in a user friendly
and efficient way. The NMS applications designed with several hierarchical levels of
GUI’s, shall have the possibilities to present critical events on all GUI levels.

717.1.9 Provide descriptions for all NMS interfaces, including but not limited to, those for
Configuration and Inventory data, Fault Management and Performance Management. The
NMS shall have single platform architecture and multi-vendor interfaces.

717.1.10 It shall be supported to perform automatic monitoring of the NMS behavior (including all
HW and SW components) through use of monitoring agents (own - or 3rd. party).
Monitoring agents could communicate with a remote NMS over a DCN (Data
Communication Network) by means of a management protocol, such as SNMP, XML/JMS
or Web Services.

717.1.11 Dependencies to particular product versions across value chains shall be kept to a
minimum.

717.1.12 In case of integration to higher level “Umbrella system” the notification of alarms and
events shall be done in strict order of occurrence in the managed Network.

717.1.13 The NMS shall support interfaces to third-party integrated management systems (IMS)
performing Network Management functions, e.g. Fault Management, Performance
Management, Configuration Management, etc.

717.1.14 NMS has to have a CAL (Current Alarm List) exposed through north bound interface so
that any “Umbrella system” are capable to resynchronize any time on demand.

717.1.15 Every alarm, measurement, configuration, operation and maintenance data stored in the
database shall be able to be accessed using external tools.

717.1.16 The NMS shall support storing of all data in Oracle or other relational database based on
SQL standard.

718.1.2 It shall be possible to search in the alarm history for certain alarms by filtering on any
alarm information. It shall be possible to filter out alarms at system and user-level.
Descriptions of available alarm filtering shall be provided.

718.1.3 The NMS shall support transfer of alarms (or other information) to one or several
MSISDN, e.g. via GSM/UMTS Short Message Service, GPRS or by E-mail.

718.1.4 Alarm documentation shall be available from the NMS.

718.1.5 The NMS solution shall have a correlation engine available for correlating alarms.

718.1.6 The alarm reporting interface shall be based on TCP or similar protocols.

718.1.7 The NMS shall provide an open and fully documented file based northbound interface
towards overlaid Fault Management systems.

718.1.8 Northbound bi-directional alarm interface shall be supported when applicable.

718.1.9 The NMS shall be possible to define alarms based on statistics.

718.1.10 The NMS shall be possible to define alarms.

718.1.11 The NMS shall be possible to pre-define alarm thresholds.

718.1.12 The NMS shall be possible to define different alarm categories and levels.

718.1.13 The NMS shall be possible to activate/deactivate the different alarms.

718.1.14 The NMS shall be possible to automatically delete alarms.

718.1.15 The NMS shall be possible to set up filters for predefined alarms.

718.1.17 The EM itself shall be “monitored” for functionality and performance.

718.1.18 The EM shall be able to suppress the generation of alarm and event notifications destined
for the fault monitoring system. This capability is referred to as Event Forwarding
Discrimination (EFD). It shall be possible to suppress alarm and event notification.

718.1.19 Describe the alarm severity for various alarm generated in EM.

718.1.20 The bidder should support Exclusion of ‘non-alarm’ events.

718.1.21 The bidder undertakes to provide a fully redundant & high-availability solution in order to
serve all the requested capacity & requested features / functions..

718.1.22 The NMS will provide post processing capabilities for the collected information related to
the fault management reports to show the current and history alarm situation of the
network.

718.1.23 The Vendor shall describe which alarms that are stored in the NMS alarm database and
that can be exported to another data source for further processing.

718.1.24 The NMS shall be capable of automatically notifying operator of any alarm/event e.g. via
audio notification (pager, telephone, etc) or SMS or by email.

718.1.25 Performed alarm surveillance on the managed Network Element with graphical network
representation.

718.1.26 Upon detection of new alarms, that information shall be displayed on the graphical
network representation with audible signal as an optional features.

718.1.27 The notification of Alarms (usually in the form of an alarm message) and Events (in the
form of event messages) is required to include sufficient information to allow unambiguous
identification of the type of alarm/event from a list explicitly provided in MIBS and Alarm
documentation.

719.1.2 Preparing and activating multiple plans shall be possible independently and
simultaneously.

719.1.3 Full traceability at any configuration changes must be ensured in NMS.

719.1.4 The NMS shall have functionality for automatic import of configuration data on a
predefined format.

719.1.5 Any configuration changes in the network must be done through an open and fully
documented interface such as XML.

719.1.6 The NMS shall maintain the configuration inventory for all changeable parameters in the
network.

719.1.7 Activating plans to the network shall be done in a transaction oriented process with both
commit and rollback mechanisms.

719.1.8 The Vendor shall list any configuration tasks that are available via CLI.

719.1.9 The vendor shall list any configuration tasks that are available via GUI only.

719.1.10 The network topology and object relationships shall be stored in the NMS

719.1.11 The vendor shall list all configuration tasks that can be performed via scripts or
configuration files.

719.1.12 The NMS shall be provided with visualization for all configuration data stored in each
managed NE that properly reflects the actual data stored in the managed NE.

719.1.13 When the operational state of a managed entity within a NE changes, the NMS shall
provide notification and log.

719.1.14 The NE entity or functionality shall allow for version control and tracking for configuration
files and software load files

720.1.2 NMS shall have performance reporting functionality and user shall be able to query to
performance database using that functionality.

720.1.3 The following performance management data shall as a minimum be supported:

 Performance data
 Performance event
 Event statistics
 Counters
 Performance thresholds
 Measurements
 Measurement interval
 Load on NEs, number of service executions
 Network Performance Key Performance Indicator (KPI)

720.1.4 The NMS shall be possible to activate and deactivate counters, to choose different
measuring intervals and to automatically produce statistical reports.

720.1.5 Automatic data deletion shall be possible.

720.1.6 Describe the retention period for storing performance measurement data.

720.1.7 The NMS shall export statistics automatically in common formats from NE to NMS and to
other external systems, such as data warehouses and CRM systems. The specific export
format shall be described.

720.1.8 The vendor shall describe, for each set of performance measurement counters, at what
granularity the counters can be reported.

720.1.9 The vendor shall provide a description of the performance management functionality and
all performance measurement counters available

720.1.11 The vendor shall describe how the measured results can be presented and visualized.

720.1.12 The EM shall provide sufficient performance statistics information that reflect the true
performance of the managed network.

720.1.13 The NMS shall monitor its own resource requirements and raise an alarm if any of these
are in danger of being breached.

720.1.14 The EM shall have the capability to detect all violations of pre-defined performance
threshold values.

721.1.2 The NMS shall support Data integrity to protect against unauthorized data access and
manipulation.

721.1.3 The NMS shall identify the users by a unique user ID. Describe the rule which all user ID
must satisfy e.g. minimum length of character and the use of numbers and alphabetical
characters.

721.1.4 The NMS shall require each user ID to have an associated password.

721.1.5 The NMS shall require users to identify themselves with their assigned user ID and
password before performing any actions.

721.1.6 The NMS shall internally maintain the identity of all active users.

721.1.7 The NMS shall have an activity log with login and logout information per user and per
application. Each add/delete/edit task shall be logged.

721.1.8 The NMS shall give appropriate support for password strategies (e.g. minimum and
maximum number of characters, requirements on the type of characters).

721.1.9 The key length should be 2048 or more.

721.1.10 The security administrator shall be able to create, delete and maintain all users ID’s
accessing the EM.

721.1.11 The security administrator shall be able to define and maintain user’s access right in the
access control list.

721.1.12 NMS passwords and other authentication data shall be encrypted in the database and the
encrypted password file shall only be accessible by the System Administrator.

721.1.13 The EM shall support password aging period and user account deactivation after a period
of time due to inactive account.

721.1.15 The procedures for definition of access categories and administration and control of users
and interfaces shall be simple. The vendor shall describe these procedures.

721.1.16 NE, NMS shall have Element, platform or system has module to manage user groups or
profiles, their access rights with different access control levels (i.e. admin, developer,
super-user, end-user) according to ‘user-privileges’ and user roles / job descriptions.

721.1.17 Any component should not have hard coded or shared sensitive parameters like user
account and passwords and/or IP address within the code. If that is the case passwords
cannot appear in plain text in any file i.e. it must be protected by appropriate security
mechanism.

721.1.18 An internationally accepted algorithm or method of encryption is employed for keeping of

passwords’ contents (e.g. SHA-1).

721.1.19 The amount of data to be recorded by the element, platform or system shall support the
configuration for:

 all actions performed by administrators (creation, changes, deletion of users, their

access rights and operational parameters)
 all relevant actions performed by the end users at least:
 timestamp of the action,
 kind of action or form accessed by user,
 user account,
 source IP Address,
 type of action (view, insert, change, update, delete etc.)
 result of action (success/fail)

721.1.20 Operating systems logs should be configured to contain:

 time stamp of each entry,

 successful and failed login attempts,

721.1.21 In cases of errors or execution problems and especially when databases are involved, the
application has appropriate error handling mechanisms to ensure a secure continuity of
relevant operations.

721.1.22 The EM shall support alarm forwarding via Transmission Control Protocol/Internet
Protocol (TCP/IP) SSH session or Simple Network Management Protocol (SNMP) suite.

722. Software Management

722.1.1 It shall be possible to download new software to NE.This operation shall be possible also
from a remote site.

722.1.2 The NMS shall support to maintain multiple software versions throughout the network.

722.1.3 It shall be possible to schedule the download and installation of new software to any NE.
A description of this functionality shall be provided.

722.1.4 NMS software upgrades shall be done with a formal and predictable software upgrade
mechanism.

723.1.2 The NMS shall be possible to retrieve lists of filtered information about all relevant
hardware details (type, serial number) of connected network elements.

723.1.3 The NMS shall provide the capability to navigate to a selected object, result of the search.
As a result, a graphical representation of the selected object shall be displayed to the
operator.

723.1.4 The NMS shall allow to retrieve provide following software-related information about the
NE’s for example:

 List of all SW versions available at NE level, at board level;

 NE memory usage
 NE CPU usage

724. User Interface

724.1.1 The NMS shall provide users with support for both the Graphic User Interface (GUI)
and/or Command Line Interface (CLI) based user interfaces.

724.1.2 Faster adaptation of software to changing business needs.

724.1.3 The GUI shall present the network nodes as icons where the status of the nodes shall be
visualized by colors. It shall also present the NEs at different hierarchy levels.

724.1.4 The GUI shall present a total network view selectable by the user; while drilling down to
individual NEs, the user will be notified of new alarms from anywhere within his network
view.

724.1.5 The NMS shall allow users to access remotely via a terminal emulation interface, for
example, telnet. The vendor shall specify the maximum simultaneous telnet sessions.

724.1.6 The NMS shall allow multiple simultaneous sessions per Node.

724.1.8 The NMS should support generation of detailed messages arising from any conflict and
wrong transaction imposed on the system.

724.1.9 The NMS client should have the web-access capability using web-methods interface.

725. Resilience and Disaster Recovery

725.1.1 The NMS should support resilience and disaster recovery concept.

725.1.2 The vendor shall provide the overview and detailed information for the offered system
resilience and disaster recovery concept.

725.1.3 The system shall have recovery capabilities with appropriate logging to support root cause
analysis of a failure condition.

726. Logging
726.1.1 All NEs shall have local logging of relevant events and operations. The following types of
logs shall be implemented as minimum;

 Command log
 Alarm and event log
 Performance log (CPU and memory availability per processor)
 Logs showing abnormal interaction with other systems

726.1.2 Local logging of relevant events and operations shall be written to a non-volatile storage.

726.1.3 For all log records in log files shall support time-stamps which shall be accurate within a
second e.g. xyz.log.20011201230059 (yyyymmddhhmmss).

726.1.5 All log-messages shall be able to be distinguished for each system categories (e.g. OS,
Database, interfaces, application…).

726.1.6 The retention period of all log files shall be configurable.

726.1.7 Real- time logging shall be supported.

727. Backup and Recovery

727.1.1 Describe the backup/recovery capabilities and procedures including the ability to archive
configuration data, performance data, system data, user profile data and templates.

727.1.2 Schedulable automatic backup shall be supported.

727.1.3 Describe the procedures to restore the system from backup sets.

727.1.4 Describe which types of backup media are proposed and supported.

727.1.5 All backup / restore/ recovery process shall be logged in order to verify the completion of
each process.

728.1.2 The system shall provide a mechanism to ensure that loss of connectivity is detected, and
its correct operation is assured.

728.1.3 Explain in detail for highly scalable (unlimited) and flexible architecture.

728.1.4 Describe the possibilities for expanding the offered system in order to cater for the needs
of growing services, service objects, use cases, the number of users or the number of
interfaces.

729. Solution Roadmap

729.1.1 The vendor shall list and provide description for all basic and optional features of each NE
type, clearly identifying the software release required for feature support.

729.1.2 The vendor shall list and provide description for all basic and optional features of each
network element type, clearly identifying the software release required for feature support.

729.1.3 The vendor shall present HW life cycle plans, including End of Life charts for all
equipment.

730. Interfaces and Protocols

730.1.1 End of support on each interface shall be declared at least one year in advance in written
form.

730.1.2 All changes on each interface shall be announced in written form.

731. Documentations
731.1.1 All documentation shall be available in electronic format on the EMS.

731.1.2 The vendor shall provide the list of available operator procedures.

731.1.3 The vendor shall provide a list of all the user guides and reference manuals associated
with system administration and operations Management System

IMS Design and Log Analysis: Reference Manual
No ratings yet
IMS Design and Log Analysis: Reference Manual
179 pages
Volte SRVCC
100% (5)
Volte SRVCC
41 pages
MTCWE
No ratings yet
MTCWE
43 pages
SBC - Troubleshooting Guide-21.8
No ratings yet
SBC - Troubleshooting Guide-21.8
110 pages
Vehicular Networking Slides
No ratings yet
Vehicular Networking Slides
408 pages
IMS Emergency Call Support v1C
100% (1)
IMS Emergency Call Support v1C
9 pages
QoS Strategies For IMS & VoLTE
No ratings yet
QoS Strategies For IMS & VoLTE
19 pages
22 VoLTE Call Steps Fi
100% (1)
22 VoLTE Call Steps Fi
309 pages
GSM Call Routing
100% (1)
GSM Call Routing
22 pages
22 - Call Flow PDF
100% (1)
22 - Call Flow PDF
114 pages
Ericsson - WCDMA
No ratings yet
Ericsson - WCDMA
9 pages
Simodrive Cable Connection PDF
No ratings yet
Simodrive Cable Connection PDF
2 pages
Ims Conference Call PDF
100% (1)
Ims Conference Call PDF
6 pages
Industrial Network Security Architecture
100% (3)
Industrial Network Security Architecture
96 pages
VoLTE Seminar Document
100% (1)
VoLTE Seminar Document
20 pages
VoLTE Basic Call Flows v4
100% (3)
VoLTE Basic Call Flows v4
75 pages
IMS Originating To IMS Terminating Call (Caller
100% (1)
IMS Originating To IMS Terminating Call (Caller
5 pages
Wireless Communications: Uniforum Chicago Bill Latura
100% (1)
Wireless Communications: Uniforum Chicago Bill Latura
48 pages
The Five Layer Model
100% (4)
The Five Layer Model
5 pages
CMM Basis and Troubleshoting
No ratings yet
CMM Basis and Troubleshoting
56 pages
Statement of Account 3 27 Nov 18 To 26 Dec 18 878382480 (72) 2062796
100% (1)
Statement of Account 3 27 Nov 18 To 26 Dec 18 878382480 (72) 2062796
2 pages
True of False: H12-111-Enu Hcia-Iot V2.5 Exam
100% (4)
True of False: H12-111-Enu Hcia-Iot V2.5 Exam
20 pages
CALL Flow Procedure
No ratings yet
CALL Flow Procedure
54 pages
Volte Ims Architecture and Sip Signalling
100% (3)
Volte Ims Architecture and Sip Signalling
60 pages
VoLTE Basics - NTAS, CFX and SBC Overview
No ratings yet
VoLTE Basics - NTAS, CFX and SBC Overview
20 pages
Very Imp - VoLTE Call Flows
No ratings yet
Very Imp - VoLTE Call Flows
9 pages
Case Study VoLTE
No ratings yet
Case Study VoLTE
11 pages
vEPC Overview
100% (2)
vEPC Overview
121 pages
Module 1 - VoLTE Training VoLTE Settings
100% (1)
Module 1 - VoLTE Training VoLTE Settings
45 pages
Voice and Communication Services
No ratings yet
Voice and Communication Services
23 pages
Volte Call Flow
No ratings yet
Volte Call Flow
10 pages
5g Protocol Testing
No ratings yet
5g Protocol Testing
3 pages
One-Nds Brochure
50% (2)
One-Nds Brochure
2 pages
VoLTE Solution Overview
100% (2)
VoLTE Solution Overview
70 pages
VoLTE - E2E Message Flows
No ratings yet
VoLTE - E2E Message Flows
42 pages
Base Station OMCH Self-Recovery (SRAN13.1 - 01)
100% (1)
Base Station OMCH Self-Recovery (SRAN13.1 - 01)
31 pages
Volte Ims Lte Ov
100% (1)
Volte Ims Lte Ov
45 pages
Arista Eos Rn-4.19.1f
No ratings yet
Arista Eos Rn-4.19.1f
26 pages
IMS Basic Concepts and Network Structure-20091029-A-1.0
100% (1)
IMS Basic Concepts and Network Structure-20091029-A-1.0
106 pages
IMS Call Flows
100% (1)
IMS Call Flows
40 pages
1 Data Sheet Nokia Cloud Mobile Gateway
No ratings yet
1 Data Sheet Nokia Cloud Mobile Gateway
8 pages
01 Introduction P 44
100% (2)
01 Introduction P 44
46 pages
Nokia Session Border Controller Data Sheet en
No ratings yet
Nokia Session Border Controller Data Sheet en
8 pages
IMS Call Flows1
100% (2)
IMS Call Flows1
14 pages
HWI - Protocol and Signaling Analysis
No ratings yet
HWI - Protocol and Signaling Analysis
197 pages
STBC
No ratings yet
STBC
25 pages
SMSGW & SMSC PDF
100% (1)
SMSGW & SMSC PDF
24 pages
Ims-Volte - Sip: - Kiran Koona
100% (1)
Ims-Volte - Sip: - Kiran Koona
29 pages
ER00743-V-1900-CE-PDF Mobile Gateway Product Overview
No ratings yet
ER00743-V-1900-CE-PDF Mobile Gateway Product Overview
69 pages
Cause Code Mappings
No ratings yet
Cause Code Mappings
5 pages
Software Defined Networking (SDN) Overview: Includes Material From Scott Shenker and Nick Mckeown
No ratings yet
Software Defined Networking (SDN) Overview: Includes Material From Scott Shenker and Nick Mckeown
28 pages
Clustered Data ONTAP 82 Network Management Guide
No ratings yet
Clustered Data ONTAP 82 Network Management Guide
111 pages
Number Analysis Huawei - MSC
100% (1)
Number Analysis Huawei - MSC
4 pages
Ericsson MSS Kpi-Formulae
100% (1)
Ericsson MSS Kpi-Formulae
13 pages
25 ZTE IP RAN Introduction (Slide)
100% (1)
25 ZTE IP RAN Introduction (Slide)
28 pages
UMTS Signaling Trace and Analysis: Internal
No ratings yet
UMTS Signaling Trace and Analysis: Internal
38 pages
5G Core
100% (1)
5G Core
18 pages
Dovado Tiny Reference Manual 6.1.1
No ratings yet
Dovado Tiny Reference Manual 6.1.1
24 pages
LTE Roaming DRA Traffix
100% (1)
LTE Roaming DRA Traffix
21 pages
IMS Information Gateway - VoLTE Signaling Analysis Manualú¿VoLTE Call Flowú® PDF
100% (1)
IMS Information Gateway - VoLTE Signaling Analysis Manualú¿VoLTE Call Flowú® PDF
1 page
Computer Networks Notes-Shashi
No ratings yet
Computer Networks Notes-Shashi
27 pages
Nokia Cloudband Application Manager: Benefits
100% (1)
Nokia Cloudband Application Manager: Benefits
4 pages
1 VoLTE Solution Overview ISSUE 1.00
No ratings yet
1 VoLTE Solution Overview ISSUE 1.00
70 pages
5G-Physical Terminologis
No ratings yet
5G-Physical Terminologis
25 pages
Understanding The Benefits of Voice Over IP (VOIP) Vs Traditional Phone Services
No ratings yet
Understanding The Benefits of Voice Over IP (VOIP) Vs Traditional Phone Services
4 pages
VOLTE Activation Procedure v2
No ratings yet
VOLTE Activation Procedure v2
8 pages
Volte Call Flow
No ratings yet
Volte Call Flow
6 pages
Nokia 5G Solution: Available As PDF Duration: 16 Min
No ratings yet
Nokia 5G Solution: Available As PDF Duration: 16 Min
16 pages
Lte Epc Ims Call Flow
100% (1)
Lte Epc Ims Call Flow
17 pages
LTE CS Fallback (CSFB) Call Flow Procedure - 3GLTEInfo
No ratings yet
LTE CS Fallback (CSFB) Call Flow Procedure - 3GLTEInfo
9 pages
Lte Volte Rjil
No ratings yet
Lte Volte Rjil
16 pages
SRVCC PDF
No ratings yet
SRVCC PDF
5 pages
1.SMS Interworking in Traditional Network 1.1.mobile Originated - SMS
No ratings yet
1.SMS Interworking in Traditional Network 1.1.mobile Originated - SMS
7 pages
IEEE 802.15.4 and Zigbee Overview
No ratings yet
IEEE 802.15.4 and Zigbee Overview
22 pages
Samsung Case Smart VoLTE Solution
No ratings yet
Samsung Case Smart VoLTE Solution
11 pages
Clock Signal Component Issue
No ratings yet
Clock Signal Component Issue
4 pages
CN6530-92A One-NDS 9 SP2 Directory Platform and Operation
0% (1)
CN6530-92A One-NDS 9 SP2 Directory Platform and Operation
3 pages
Lecture 0: Course Overview: Instructor: DR Seif Allah Nasri
No ratings yet
Lecture 0: Course Overview: Instructor: DR Seif Allah Nasri
8 pages
Chapter 5 Management Information Systems
No ratings yet
Chapter 5 Management Information Systems
34 pages
1.1 Definitions: Communication Systems I, First Edition. 2015 John Wiley & Sons, Inc
No ratings yet
1.1 Definitions: Communication Systems I, First Edition. 2015 John Wiley & Sons, Inc
7 pages
Redline Solutions Brochure
No ratings yet
Redline Solutions Brochure
4 pages
WWW Phcorner Net Threads 109602
No ratings yet
WWW Phcorner Net Threads 109602
6 pages
Manual de CCNA 5
No ratings yet
Manual de CCNA 5
3 pages
Advanced Firewall 2016 Web en
No ratings yet
Advanced Firewall 2016 Web en
3 pages
Sponsored Roaming 0110
No ratings yet
Sponsored Roaming 0110
2 pages
Voice over LTE: VoLTE
From Everand
Voice over LTE: VoLTE
Miikka Poikselkä
4.5/5 (2)
Voice over LTE Standard Requirements
From Everand
Voice over LTE Standard Requirements
Gerardus Blokdyk
3/5 (1)
Drive testing The Ultimate Step-By-Step Guide
From Everand
Drive testing The Ultimate Step-By-Step Guide
Gerardus Blokdyk
No ratings yet
IP Multimedia Subsystem IMS A Complete Guide
From Everand
IP Multimedia Subsystem IMS A Complete Guide
Gerardus Blokdyk
No ratings yet
Diameter Protocol A Complete Guide
From Everand
Diameter Protocol A Complete Guide
Gerardus Blokdyk
No ratings yet