Archive | IMS RSS feed for this section

5G Network Slicing – Separating the Internet of Things from the Internet of Talk

1 Mar

Recognized now as a cognitive bias known as the frequency illusion, this phenomenon is thought to be evidence of the brain’s powerful pattern-matching engine in action, subconsciously promoting information you’ve previous deemed interesting or important. While there is far from anything powerful between my ears, I think my brain was actually on to something. As the need to support an increasingly diverse array of equally critical but diverse services and endpoints emerges from the 4G ashes, network slicing is looking to be a critical function of 5G design and evolution.

Euphoria subsiding, I started digging a little further into this topic and it was immediately apparent that the source of my little bout of déjà vu could stem from the fact that network slicing is in fact not one thing but a combination of mostly well-known technologies and techniques… all bundled up into a cool, marketing-friendly name with a delicately piped mound of frosting and a cherry on top. VLAN, SDN, NFV, SFC — that’s all the high-level corporate fluff pieces focused on. We’ve been there and done that.2

5g-slicing-blog-fluff.png

An example of a diagram seen in high-level network slicing fluff pieces

I was about to pack up my keyboard and go home when I remembered that my interest had originally been piqued by the prospect of researching RAN virtualization techniques, which must still be a critical part of an end-to-end (E2E) 5G network slicing proposition, right? More importantly, I would also have to find a new topic to write about. I dug deeper.

A piece of cake

Although no one is more surprised than me that it took this long for me to associate this topic with cake, it makes a point that the concept of network slicing is a simple one. Moreover, when I thought about the next step in network evolution that slicing represents, I was immediately drawn to the Battenberg. While those outside of England will be lost with this reference,3 those who have recently binge-watched The Crown on Netflix will remember the references to the Mountbattens, which this dessert honors.4 I call it the Battenberg Network Architecture Evolution principle, confident in the knowledge that I will be the only one who ever does.

5g-slicing-blog-battenberg-network-evolution.png

The Battenberg Network Architecture Evolution Principle™

Network slicing represents a significant evolution in communications architectures, where totally diverse service offerings and service providers with completely disparate traffic engineering and capacity demands can share common end-to-end (E2E) infrastructure resources. This doesn’t mean simply isolating traffic flows in VLANs with unique QoS attributes; it means partitioning physical and not-so-physical RF and network functions while leveraging microservices to provision an exclusive E2E implementation for each unique application.

Like what?

Well, consider the Internet of Talk vs. the Internet of Things, as the subtitle of the post intimates. Evolving packet-based mobile voice infrastructures (i.e. VoLTE) and IoT endpoints with machine-to-person (M2P) or person-to-person (P2P) communications both demand almost identical radio access networks (RAN), evolved packet cores (EPC) and IP multimedia subsystem (IMS) infrastructures, but have traffic engineering and usage dynamics that would differ widely. VoLTE requires the type of capacity planning telephone engineers likely perform in their sleep, while an IoT communications application supporting automatic crash response services5 would demand only minimal call capacity with absolutely no Mother’s Day madness but a call completion guarantee that is second to none.

In the case of a network function close to my heart — the IMS Core — I would not want to employ the same instance to support both applications, but I would want to leverage a common IMS implementation. In this case, it’s network functions virtualization (NFV) to the rescue, with its high degree of automation and dynamic orchestration simplifying the deployment of these two distinct infrastructures while delivering the required capacity on demand. Make it a cloud-native IMS core platform built on a reusable microservices philosophy that favors operating-system-level virtualization using lightweight containers (LCXs) over virtualized hardware (VMs), and you can obtain a degree of flexibility and cost-effectiveness that overshadows plain old NFV.

I know I’m covering a well-trodden trail when I’m able to rattle off a marketing-esque blurb like that while on autopilot and in a semi-conscious state. While NFV is a critical component of E2E network slicing, things get interesting (for me, at least) when we start to look at the virtualization of radio resources required to abstract and isolate the otherwise common wireless environment between service providers and applications. To those indoctrinated in the art of Layer 1-3 VPNs, this would seem easy enough, but on top of the issue of resource allocation, there are some inherent complications that result from not only the underlying demand of mobility but the broadcast nature of radio communications and the statistically random fluctuations in quality across the individual wireless channels. While history has taught us that fixed bandwidth is not fungible,6 mobility adds a whole new level of unpredictability.

The Business of WNV

Like most things in this business, the division of ownership and utilization can range from strikingly simple to ridiculously convoluted. At one end of the scale, a mobile network operator (MNO) partitions its network resources — including the spectrum, RAN, backhaul, transmission and core network — to one or more service providers (SPs) who use this leased infrastructure to offer end-to-end services to their subscribers. While this is the straightforward MNV model and it can fundamentally help increase utilization of the MNOs infrastructure, the reality is even easier, in that the MNO and SP will likely be the same corporate entity. Employing NFV concepts, operators are virtualizing their network functions to reduce costs, alleviate stranded capacity and increase flexibility. Extending these concepts, isolating otherwise diverse traffic types with end-to-end wireless network virtualization, allows for better bin packing (yay – bin packing!) and even enables the implementation of distinct proof-of-concept sandboxes in which to test new applications in a live environment without affecting commercial service.

2-and-4-layer-models-5g-slicing-blog.png

Breaking down the 1-2 and 4-layer wireless network virtualization business model

Continuing to ignore the (staggering, let us not forget) technical complexities of WNV for a moment, while the 1-2 layer business model appears to be straightforward enough, to those hell-bent on openness and micro business models, it appears only to be monolithic and monopolistic. Now, of course, all elements can be federated.7 This extends a network slice outside the local service area by way of roaming agreements with other network operators, capable of delivering the same isolated service guarantees while ideally exposing some degree of manageability.

To further appease those individuals, however, (and you know who you are) we can decompose the model to four distinct entities. An infrastructure provider (InP) owns the physical resources and possibly the spectrum which the mobile virtual network provider then leases on request. If the MVNP owns spectrum, then that component need not be included in the resource transaction. A widely recognized entity, the mobile virtual network operator (MVNO) operates and assigns the virtual resources to the SP. In newer XaaS models, the MVNO could include the MVNP, which provides a network-as-a-service (NaaS) by leveraging the InPs infrastructure-as-a-service (IaaS). While the complexities around orchestration between these independent entities and their highly decomposed network elements could leave the industry making an aaS of itself, it does inherently streamline the individual roles and potentially open up new commercial opportunities.

Dicing with RF

Reinforcing a long-felt belief that nothing is ever entirely new, long before prepending to cover all things E2E, the origin of the term “slicing” can be traced back over a decade in texts that describe radio resource sharing. Modern converged mobile infrastructures employ multiple Radio Access Technologies (RATs), both licensed spectrum and unlicensed access for offloading and roaming, so network slicing must incorporate techniques for partitioning not only 3GPP LTE but also IEEE Wi-Fi and WiMAX. This is problematic in that these RATs are not only incompatible but also provide disparate isolation levels — the minimum resource units that can be used to carve out the air interface while providing effective isolation between service providers. There are many ways to skin (or slice) each cat, resulting in numerous proposals for resource allocation and isolation mechanisms in each RF category, with no clear leaders.

At this point, I’m understanding why many are simply producing the aforementioned puff pieces on this topic — indeed, part of me now wishes I’d bowed out of this blog post at the references to sponge cake — but we can rein things in a little.  Most 802.11 Wi-Fi slicing proposals suggest extending existing QoS methods — specifically, enhanced DCF (distributed coordination function) channel access (EDCA) parameters. (Sweet! Nested acronyms. Network slicing might redeem itself, after all.) While (again) not exactly a new concept, the proposals advocate implementing a three-level (dimensional) mathematical probability model know as a Markov chain to optimize the network by dynamically tuning the EDCA contention window (CW), arbitration inter-frame space (AIFS) and transmit opportunity (TXOP) parameters,8 thereby creating a number of independent prioritization queues — one for each “slice.” Early studies have already shown that this method can control RF resource allocation and maintain isolation even as signal quality degrades or suffers interference. That’s important because, as we discussed previously, we must overcome the variations in signal-to-noise ratios (SNRs) in order to effectively slice radio frequencies.

In cellular networks, most slicing proposals are based on scheduling (physical) resource blocks (P/RBs), the smallest unit the LTE MAC layer can allocate, on the downlink to ensure partitioning of the available spectrum or time slots.

5g-slicing-blog-prb.png

An LTE Physical Resource Block (PRB), comprising 12 subcarriers and 7 OFDM symbols

Slicing LTE spectrum, in this manner, starts and pretty much ends with the eNodeB. To anyone familiar with NFV (which would include all you avid followers of Metaswitch), that would first require virtualization of that element using the same fundamental techniques we’ve described in numerous posts and papers. At the heart of any eNodeB virtualization proposition is an LTE hypervisor. In the same way classic virtual machine managers partition common compute resources, such as CPU cycles, memory and I/O, an LTE hypervisor is responsible for scheduling the physical radio resources, namely the LTE resource blocks. Only then can the wireless spectrum be effectively sliced between independent veNodeB’s owned, managed or supported by the individual service provider or MVNO.

5g-slicing-blog-virtual-eNobeB.png

Virtualization of the eNodeB with PRB-aware hypervisor

Managing the underlying PRBs, an LTE hypervisor gathers information from the guest eNodeB functions, such as traffic loads, channel state and priority requirements, along with the contract demands of each SP or MVNO in order to effectively slice the spectrum. Those contracts could define fixed or dynamic (maximum) bandwidth guarantees along with QoS metrics like best effort (BE), either with or without minimum guarantees. With the dynamic nature of radio infrastructures, the role of the LTE hypervisor is different from a classic virtual machine manager, which only need handle physical resources that are not continuously changing. The LTE hypervisor must constantly perform efficient resource allocation in real time through the application of an algorithm that services those pre-defined contracts as RF SNR, attenuation and usage patterns fluctuate. Early research suggests that an adaptation of the Karnaugh-map (K-map) algorithm, introduced in 1953, is best suited for this purpose.9

Managing the distribution of these contracted policies across a global mobile infrastructure falls on the shoulders of a new wireless network controller. Employing reasonably well-understood SDN techniques, this centralized element represents the brains of our virtualized mobile network, providing a common control point for pushing and managing policies across highly distributed 5G slices. The sort of brains that are not prone to the kind of cognitive tomfoolery that plague ours. Have you ever heard of the Baader-Meinhof phenomenon?

1. No one actually knows why the phenomenon was named after a West German left wing militant group, more commonly known as the Red Army Faction.

2. https://www.metaswitch.com/the-switch/author/simon-dredge

3. Quite frankly, as a 25-year expat and not having seen one in that time, I’m not sure how I was able to recall the Battenberg for this analogy.

4. Technically, it’s reported to honor of the marriage of Princess Victoria, a granddaughter of Queen Victoria, to Prince Louis of Battenberg in 1884. And yes, there are now two footnotes about this cake reference.

5. Mandated by local government legislation, such as the European eCall mandate, as I’ve detailed in previous posts. https://www.metaswitch.com/the-switch/guaranteeing-qos-for-the-iot-with-the-obligatory-pokemon-go-references

6. E.g. Enron, et al, and the (pre-crash) bandwidth brokering propositions of the late 1990s / early 2000s

7. Yes — Federation is the new fancy word for a spit and a handshake.

8. OK – I’m officially fully back on the network slicing bandwagon.

9. A Dynamic Embedding Algorithm for Wireless Network Virtualization. May 2015. Jonathan van de Betl, et al.

Source: http://www.metaswitch.com/the-switch/5g-network-slicing-separating-the-internet-of-things-from-the-internet-of-talk

IR.51 IMS OVER WI-FI V3.0

3 Mar

The IP Multimedia Subsystem (IMS) Profile for Voice and Video, documented in this Permanent Reference Document (PRD), identifies a minimum mandatory set of features which are defined in 3GPP specifications that a wireless device (the User Equipment (UE)) and network are required to implement in order to guarantee interoperable, high quality IMS-based telephony and conversational video services over Wi-Fi access networks.

Download IMS Profile for Voice, Video and SMS over Wi-Fi – Version 3.0 – 01 March 2016

Source: http://www.gsma.com/newsroom/all-documents/ir-51-ims-over-wi-fi-v/

Introduction to SCTP and it’s benefits over TCP and UDP

29 Jun

SCTP (Stream Control Transmission Protocol) was introduced for transporting PSTN signaling messages over IP network. But due to its amazing features it became an important part of next generation network technologies i.e. IMS and LTE

Source: http://www.slideshare.net/contactvijay1988/introduction-to-sctp-and-benefits-over-tcp-and-udp-36433404

Telephony – Telco service or Internet application?

9 Jun

 

When comparing different forms of VoIP, one risk comparing “apples and oranges”. Broadly speaking, we can divide VoIP into two main categories. First, the service can be implemented as a faithful copy of circuit switched telephony; in a network with full control over performance and quality. Second, VoIP can be implemented as a standalone application used over the open Internet.

Originally published in NetworkWorld Norway.

 

3GPP and IMS

3GPP (3rd Generation Partnership Project) has played an important role when VoIP has become a recognised substitute for traditional telephony among telecom operators. 3GPP standardises the mobile technologies 2G, 3G and 4G, and they have done so based on the general IP technology standardised by IETF (Internet Engineering Task Force).

At first 3GPP concentrated on developing mobile networks as an evolving telecommunications architecture, following a vertically integrated model for provision of telephony. As the Internet revolution influenced the telecom market, the focus has shifted more towards IP-based services of various kinds.

IP networks and the Internet are not equivalent concepts. As IP technology was introduced in the mobile architecture, this was done in a way that maintained telecommunications networks’ support for QoS (Quality of Service). They had a clear view to continue provision of telecom services, as opposed to Internet applications, but based on a new IP-based network.

The service platform which was standardised as part of the mobile architecture was named IMS (IP Multimedia Subsystem). IMS is based on SIP (Session Initiation Protocol), the VoIP protocol from IETF, but extended with a comprehensive architecture for QoS. IMS has an “open” interface for service development, but requires a business agreement with the mobile operator. So this is a completely different kind of openness than the one found on the Internet where “everyone” can develop their own services.

VoLTE and RCS

The basic mobile architecture has undergone a tremendous development by 3GPP. Now we are in a phase where LTE (Long Term Evolution) is being adopted, often referred to as 4G despite the fact that it is not “real” 4G. LTE is the first 3GPP architecture that has eliminated the circuit switched domain, appearing as a pure IP network. Therefore there are great expectations for VoIP in this architecture, a functionality called VoLTE (Voice over LTE).

The transition from traditional telephony to VoIP has been going on for a long time. In mobile networks this has taken longer than expected. IMS has been around as a part of the mobile architecture for many years already. Furthermore, VoLTE includes options that could still delay this transition; LTE phones will initially combine LTE with older mobile technologies, allowing telephones to fall back to these older technologies. There is also a quasi-solution that transports traditional telecom protocols encapsulated in IP packets, so-called VoLGA (Voice over LTE via Generic Access).

The telecom industry also promotes advanced VoIP services that can stimulate the transition from traditional telephony and SMS to IP-based “equivalents” called RCS (Rich Communication Services). RCS provides services such as voice and video telephony, presence, instant messages and more, integrated in a unified user client for mobile phones that will provide seamless user experience of multimedia communication.

RCS is based on the IMS platform using SIP and SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). Thus, the basis of this is IETF protocols, but implemented in an architecture that is intended to replicate the telecom network in the shape of an IP-based multimedia network. RCS is promoted by GSMA (GSM Association) and OMA (Open Mobile Alliance). OMA is the descendant of the WAP Forum, if there are still some who remember WAP.

QoS and Policy Control

RCS seems like an impressive technology, and what is the big deal? What distinguishes this from the applications that are already in use on the Internet? A major difference is that RCS can benefit directly from the mobile network built-in mechanisms for QoS. But it is difficult to predict what will give the best user experience, multimedia services integrated in the mobile architecture or free choice among different applications offered over the Internet.

A well-known characteristic of the Internet is that it is “best effort” and can’t guarantee the quality of the communication. In the mobile architecture, QoS is a key feature across the entire design. The underlying IP network will typically be based on DiffServ (Differentiated Services) and MPLS (Multiprotocol Label Switching), both well-known technologies from IETF supporting traffic management and QoS.

In the LTE architecture, QoS is policed by a function called PCC (Policy and Charging Control). As the name suggests, not unnaturally, management of QoS and charging are two sides of the same coin. PCC controls establishment of user sessions with various performance levels, and charging information is generated based to the capacity used by the different sessions.

Initially, IMS was specified for mobile networks, but in retrospect it has been found very useful extending the scope to include fixed networks, giving a combo solution which is often referred as NGN (Next Generation Networks). This facilitates convergence between fixed and mobile networks (Fixed-Mobile Convergence).

Over-the-top (OTT)

The traditional telcos are operating in a market that is completely changed because of the Internet. This leads to a situation where the business that telecom players envision, is facing strong competition from Internet players. The Internet model is based on decoupling of applications from the network layer, as opposed to the telecom model that relies on the services that are vertically integrated with the network.

Innovative solutions that can be used “over-the-top” without specific facilitation from telecom operators, enables virtually unlimited choices for end users. Internet applications, even real-time applications such as VoIP, work fairly well without the quality architecture of NGN. Congestion control mechanisms regulate traffic load of the Internet, sharing the available capacity between users.

However, users’ choice is not easy. Such innovative solutions in some cases evolve into isolated “islands” that are not compatible with each other. Major players are trying to create their own closed ecosystems consisting of operating systems or app stores for example. On the other hand, some traditional telecom operators introduce OTT solutions to meet the competition, making use of similar means.

The future will show which model is most adaptable. Net neutrality is tasked to ensure that the Internet model can develop freely. Meanwhile, the Norwegian guidelines for net neutrality are balanced, allowing the telecom model to evolve in parallel. This is often referred to as “specialised services”, as opposed to the Internet access service that works as a general electronic communication service.

Source: http://ipfrode.wordpress.com/2013/01/21/telephony-telco-service-or-internet-application/

IMS Structure

2 Jun

File:IMS Structure.png

Abbreviation Meaning
ATCF Access Transfer Control Function
ATGW Access Transfer Gateway
BGCF Breakout Gateway Control Function
EATF Emergency Access Transfer Function
E-CSCF Emergency Call Session Control Function
GGSN Gateway GPRS Support Node
HSS Home Subscriber Server
I-BCF Interconnection Border Control Function
I-BGF Interconnection Border Gateway Function
I-CSCF Interrogating Call Session Control Function
IM-MGW IMS Multi Media Gateway
IMS IP Multimedia Subsystem
IM-SSF IP Multimedia Service Switching Function
IP-SM-GW IP Short Message Gateway
MGCF Media Gateway Control Function
MGW Media Gateway
MME Mobility Management Entity
MMTel Multimedia Telephony Service
MRFC Multimedia Resource Function Controller
MRFP Multimedia Resource Function Processor
MSS Mobile Switching Server
PCRF Policy and Charging Rules Function
P-CSCF Proxy Call Session Control Function
SAE-GW System Architecture Evolution Gateway
SBC Session Border Controller
SCC-AS Service Centralization and Continuity Application Server
SCP Service Control Point
S-CSCF Service Call Session Control Function
SGSN Serving GPRS Support Node
SLF Subscriber Locator Function
SMSC Short Message Service Centre
TrGW Trunking Gateway

 

Source: 

LTE means rethinking security in the All-IP world

2 Jun

As communications service providers (CSPs) continue to build and deploy 4G LTE networks, they are finding that they need to understand some critical concepts as they move from circuit switched 2G and 3G networks to all IP packet switched networks.  Of these, IP security rides high on that list of technologies to master. The Internet has become an open environment susceptible to malicious activity. If your assets are not secured, you are guaranteed to be attacked and compromised by one or more unscrupulous organisations. 

They may do it for financial gain, selling the stolen data to parties, as a paid service, for your competitors to disrupt your business, or even just for personal enjoyment because they found that they could compromise your infrastructure. We may not use resources such as the M61 Vulcan shown in the picture, it is important to develop and implement the proper security tools to protect the latest wireless networks.

Growth in the Data Plane

While many CSPs already have solutions in place to protect parts of the packet data network (PDN) infrastructure, they often do not understand how the implementation of a 4G LTE network architecture changes the security requirements. The S/Gi interface, or the part of the network connecting the mobile subscribers to the Internet will have a significant increase in data volumes as more LTE enabled mobile devices are used. In addition, with the increased speeds available, we expect to see 4G wireless technologies competing with fixed-line data services such as DSL and cable. This will change the type of content seen and the mobile CSP will need to develop enhanced policies to manage and secure these services.

Another concern is that LTE expects the mobile devices to be IPv6 enabled, while much of the PDN is still expected to be using IPv4 technologies for some time.  This requires the ability to translate IPv6 addresses to IPv4 addresses using a carrier-grade NAT (CGNAT) technology, while maintaining a proper security infrastructure. This includes the ability to protect the pool of IPv4 addresses being used in the CGNAT solution and all of the devices’ communications being translated.

Packets in the Control Plane

More significantly, the control plane of the LTE network will change from a circuit-switched network to an IP-based architecture.  Diameter, SIP and DNS are the primary protocols that will be used to manage the control plane as the CSPs start implementing voice over LTE (VoLTE).  Securing and managing this infrastructure will be critical to the services delivered to the subscribers and protecting their privacy.  The Home Subscriber Service (HSS) and Policy Charging and Rules Function (PCRF) depend on Diameter, an open standardised protocol used on IP networks, while the Call Session and Control Function (CSCF) systems and Application Servers (AS) within the IP Multimedia Subsystem (IMS) utilise another public standardised communication technology called Session Initiation Protocol (SIP).

f5_pic2

Figure 1. The complexity of the IMS network architecture

It is important to note that third-party applications developed by independent people in addition to the subscribers and their LTE device will have direct access to the IMS network components through the SIP protocol. This means that potential malicious or poor programming will have the ability to directly affect and access the control plane of the LTE network and be able to disrupt it or obtain unauthorised access to private information such as subscriber profiles, unless proper security measures are put in place.

The CSPs need to understand the implications of migrating to an IP network infrastructure and how the packet-based network must be managed significantly differently from the legacy circuit-switched environment. Proper planning and testing is required to successfully build a robust and secure 4G LTE network. It is important to leverage the existing work done on IP networks over the past 20 years, utilise the knowledge of your colleagues and vendors. Apply the proper availability and security practices learned from these resources to design the next generation wireless networks.

Source: http://lteconference.wordpress.com/tag/f5/

VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)

17 Feb

Voice over LTE or VoLTE has many problems to solve. One of the issues that did not have a clear solution initially was Roaming. iBasis has a whitepaper on this topic here, from which the above picture is taken. The following is what is said above:

The routing of international calls has always been a problem for mobile operators. All too often the answer—particularly in the case of ‘tromboning’ calls all the way back to the home network—has been inelegant and costly. LTE data sessions can be broken out locally, negating the need for convoluted routing solutions. But in a VoIMS environment all of the intelligence that decides how to route the call resides in the home network, meaning that the call still has to be routed back.

The industry’s solution to this issue is Roaming Architecture for Voice over LTE with Local Breakout (RAVEL). Currently in the midst of standardisation at 3GPP, RAVEL is intended to enable the home network to decide, where appropriate, for the VoIMS call to be broken out locally.

Three quarters of respondents to the survey said they support an industry-wide move to RAVEL for VoLTE roaming. This is emphatic in its enthusiasm but 25 per cent remains a significant share of respondents still to be convinced. Just over half of respondents said they plan to support VoIMS for LTE roaming using the RAVEL architecture, while 12.3 per cent said they would support it, but not using RAVEL.

Until RAVEL is available, 27.4 per cent of respondents said they plan to use home-routing for all VoLTE traffic, while just under one fifth said they would use a non-standard VoLTE roaming solution.

Well, the solution was standardised in 3GPP Release-11. NTT Docomo has an excellent whitepaper (embedded below) explaining the issue and the proposed solution.

In 3GPP Release 11, the VoLTE roaming and interconnection architecture was standardized in cooperation with the GSMA Association. The new architecture is able to implement voice call charging in the same way as circuit-switched voice roaming and interconnection models by routing both C-Plane messages and voice data on the same path. This was not possible with the earlier VoLTE roaming and interconnection architecture.

Anyway, here is the complete whitepaper

Source: http://blog.3g4g.co.uk/2014/02/volte-roaming-with-ravel-roaming.html

S0C4 abends in IMS

27 Jan

If you have worked on mainframe, I’m pretty sure that you would have come across the S0C4 abends in your system. When the S0C4 occurs during a file processing, jcls execution etc, its rather easy to spot and correct, as most of these will be for the way the file is accessed, spaces allocated or with file type itself. However when it comes to an IMS transaction or IMS database call it might be a little tricky to find the abend source. So hopefully with this blog I can help you out on where to look for when a S0C4 abend occurs during a IMS call.

Always stick with the thumb rule for S0C4, i.e “the program is trying to access an unobtainable/unallocated/restricted area”. Most of the abends that my team reports are occurring while executing a CBLTODLI call to retrieve a segment from the IMSDB or while switching transaction using CHNG/ISRT/PURG etc. Here the CEEDUMP(dump) that the MPP jobs creates can give you most of the information that you need to find the source of the abend but unfortunately most of us refrain to use the dump and rather go with SYSOUT. In the dump please find for the PCB names used in the DLI call and check if any of the PCB data is displayed as “Invalid address” or “Restricted area”. The PCB’s with such an error will be culprit here. (an example below)

imssoc4

Now check the PSB definition of the program/transaction (You may have to decode the PSB using the decoder utilities that’s available to your organization). Once the PSB is decoded compare the PCB definition with the program’s DLI call. Ensure the number of PCB defined in the PSB is matching with the DLI calls linkage, ensure all the segment accessed by the program is defined in PCB and also check for the PROCOPT for the PCB’s defined and ensure you are using the appropriate ones as needed by the program.  In my example above, the S0C4 occurred since PCB for the transaction was trying to access a segment which was not defined in the PSB! Hope this helps.

 

Source: http://mylearnsandnotes.wordpress.com/2014/01/26/s0c4-abends-in-ims/

IMS Connect

20 Jan

This is one of the trending topics in this new era of mainframe development. If you are a mainframe junkie like me, then I’m sure you would know that our clients are consistently and always looking to connect with the new age client applications (written in Java, C etc.) with mainframe and its databases.  And often we have fought the same battle of integrating many middleware/brokers to see the job done. I think IMS connect can be one of the key IMS service function which will give us an upper hand in this fight.

IMS connect programming model is a gateway which provides access to IMS through TCP/IP. With help of IMS connect you can now access IMS databases and transactions services from any TCP/IP client.

–          IMS connect interacts with IMS DB through ODBM(Open Database Manager) component and it interacts with IMS TM through OTMA(Open tansaction Manager Access).

–          IMS connect reduces the design and coding effort for the client applications.

–          When managed tactically IMS connect can provide work load balancing.

–          IMS connect can also provide XML conversion support, thereby reducing the need to create/modify IMS applications to read and process the XML messages.

–          IMS connect can also be configured to incorporate the additional security featured products like RACF,AT-TLS etc.

imsconnect

For my employer we are putting together a ‘proof of concept’ on areas where IMS connect can help reduce the design constraints and even increase the processing time by eliminating the brokers/middleware in between. So far we are uncovering few challenges like need for additional servers to distribute the load, conversion of message formats etc but signs are looking good and am ‘all in’ on this one.

Source: http://mylearnsandnotes.wordpress.com/2014/01/13/ims-connect/

 

IMS deployments to reach US$4b by 2017

9 Jan

abi researchIMS Core Network deployments are edging up as operators put the necessary infrastructure and capacity in place for planned 2014 VoLTE launches, according to ABI Research.

Spending for the core network products (HSS, CSC, Media Controllers and Gateways, MSF, IBCF, SBC and P-CSCF) integral to a functioning IMS network will reach US$4 billion by 2017. “We see increasing IMS Core Network revenues through 2017, after which IMS revenues will flatten and reflect capacity expansion,” said Joe Hoffman, Research Director of ABI Research.

IMS spending for mobile 4G markets follows the LTE deployments, as operators seek to get their network coverage in place, stabilised, and compatible mobiles for VoLTE become available. The leading LTE market, North America, will peak 2015 to 2016, while the largest market, Asia-Pacific shows continued growth into the foreseeable future.

Virtualisation will be widespread since much of the IMS solution is delivered on x86 architecture and works on bare metal or virtualised platforms.

While the IMS driver is clearly VoLTE, operators will also find competitive advantage with a standardized, network-integrated solution that can also deliver superior user experience for WebRTC and OTT services under network congestion.

“Many operators will take a wait-and-see attitude as they already have 3G and CSFB for voice, but they will quickly comprehend the monetisation advantage with 4G and Voice, and adjust their strategies,” said Hoffman.

Simply put, the whole world is moving to all-IP, and 4G / IMS / VoLTE is the standard migration path for Telecom.

Source: http://entelechyasia.com/2014/01/06/ims-deployments-to-reach-us4b-by-2017/

%d bloggers like this: