How collaboration can be achieved practically ??

Ultimately - it's up to the Development Team to decide.

But something to consider is that just because the work is the same priority doesn't mean that it can all be delivered in the same iteration. The Development Team should work with the Product Owner to balance between spreading out knowledge and skills (becoming a more cross-functional team) and delivering rapidly. Maybe it makes sense to only pull a couple of these items into the Sprint, at least initially, to give the team a chance to cross-train. Or perhaps these are critically important to stakeholders and it's more important to maximize the number delivered. That needs to be a discussion between the Development Team and the Product Owner, facilitated by the Scrum Master.

Thanks Thomas..Your suggestion is good, I will try to implement this in our sprint planning tomorrow and update this thread. 

Would be very happy to know others' point of view.

My point of view is basically the same as @Thomas.  Scrum and agile in general is about letting people closest to the problem made decisions on how to deal with that problem.  The case of how the team making those decisions is entirely up to the team to decide. 

If the team decides that working in silos is best, then let them do it.  But as a Scrum Master you should be constantly encouraging them to inspect and, if found to be necessary, adapt.  This is especially important with a team that is just forming. They may choose to work in silos because that is familiar to them. But if the organization has decided that agile practices could improve the abilities to deliver value, then anything against those practices should be made apparent and inspected.  As a Scrum Master/Agile Coach, it is your role to facilitate those activities.  Do not under any conditions think that it is your job to tell people how to change. It is your job to observe and suggest opportunities for change. You help them respect the inspect/adapt loop for everything. Process, requirements, interaction between people should and are subject to inspect/adapt. 

One thing I want to point out.  Product Backlog Items do not have to be prioritized.  Per the Scrum Guide they should be ordered to best achieve goals and missions. There is no mention of prioritization, only ordering. Ordering should take many data points as input for the decisions.  For example, you have 1 PBI that has been estimated to take 18 weeks to deliver for the value desired.  You have 3 items that are estimated to take approximately 2 weeks a piece to deliver the value desired.  If the Product Owner feels that the value of the 3 items could be more beneficial to the stakeholders while the 1 large item provides more value to the company, they could choose to order the items higher in the backlog and use the time for delivering those items to continue assessing the large item.  It is really worth taking 18 weeks? Could the value statement be redefined such that value can be delivered in a series of shorter increments? A lot goes into ordering items and it isn't always based on priority.